I've been in this exact situation, and what worked for me to relieve the disappointment was twofold: 1. Identify what drew me to a project in the first place, and what task I ended up not doing when I lost interest. For me, the former was designing a game engine, and the latter was publishing it to other people. I made my peace with it, and now I know what engages me and what doesn't. 2. Involve myself in a project I am using. This has helped me stay engaged since I'm personally using what I'm working on. This has worked for me as a part of the #Friendica development team. I'm still picky about the tasks I'm taking on, but being part of a team means that what I don't do is likely to be picked up by someone else, and the other way around, I'm picking up tasks that other team members would prefer not to have to handle.
when i have an itch to scratch pertaining to software projects, and i’ve spoken to the maintainers about it, more often than not, they feel it would take the project in a direction they disagree with. it’s usually stuff pertaining to the user experience rather than stuff happening under the hood.
in other cases, i’ve asked what some of the more pressing issues needing to be fixed are, but nobody can answer. i don’t want to work on a fork of a project, so i’d like to have stuff greenlighted before i start working on it.
i could never wrap my head around how you’d get to a point where you’re a member of the core team and you’re in the loop in terms of the direction the project is taking, who’s working on what to avoid duplicate effort, etc.
arguably, there typically aren’t formal team members for FOSS projects, but in practice, there are regular contributors who have gained some trust and esteem.
Grouped answer to your last 5 tweets: Coming in hot in a project of which you don't know the unwritten philosophy is always risky. No formal team often also means no formal mission statement document you can base yourself on, so going blind you're bound to stub your little toe.
Additionally, unless you can implement it yourself, projects usually don't need additional suggestions, there's always more of them than can be worked on at any given time, so I can understand the cold shoulder.
On the other hand I'm surprised some projects weren't able to clearly state their most pressing issues. I sure know what they are for #Friendica, and I would expect any other short-staffed FOSS (redundant, I know) project maintainer to know as well.
About the how to make it to the core team, the answer is sadly very simple: you have to do stuff. Take existing tasks on, suggest a new feature with at least an implementation stub to boot, fix existing bugs, take cleanup tasks o
... show more
Grouped answer to your last 5 tweets: Coming in hot in a project of which you don't know the unwritten philosophy is always risky. No formal team often also means no formal mission statement document you can base yourself on, so going blind you're bound to stub your little toe.
Additionally, unless you can implement it yourself, projects usually don't need additional suggestions, there's always more of them than can be worked on at any given time, so I can understand the cold shoulder.
On the other hand I'm surprised some projects weren't able to clearly state their most pressing issues. I sure know what they are for #Friendica, and I would expect any other short-staffed FOSS (redundant, I know) project maintainer to know as well.
About the how to make it to the core team, the answer is sadly very simple: you have to do stuff. Take existing tasks on, suggest a new feature with at least an implementation stub to boot, fix existing bugs, take cleanup tasks on. In practice you need very little communication with the other maintainers to become a member of the core team, you just need to work regularly on the project, as much on your own as possible.
Of course, to sustain this commitment, you better be using the project's product on a regular basis. This will also provide you with a user's perspective which will assuredly give you a good idea of the most pressing issues the project currently has.
Hypolite Petovan
•1. Identify what drew me to a project in the first place, and what task I ended up not doing when I lost interest. For me, the former was designing a game engine, and the latter was publishing it to other people. I made my peace with it, and now I know what engages me and what doesn't.
2. Involve myself in a project I am using. This has helped me stay engaged since I'm personally using what I'm working on. This has worked for me as a part of the #Friendica development team. I'm still picky about the tasks I'm taking on, but being part of a team means that what I don't do is likely to be picked up by someone else, and the other way around, I'm picking up tasks that other team members would prefer not to have to handle.
That Guy From Norway
•That Guy From Norway
•That Guy From Norway
•That Guy From Norway
•That Guy From Norway
•Hypolite Petovan
•Grouped answer to your last 5 tweets: Coming in hot in a project of which you don't know the unwritten philosophy is always risky. No formal team often also means no formal mission statement document you can base yourself on, so going blind you're bound to stub your little toe.
Additionally, unless you can implement it yourself, projects usually don't need additional suggestions, there's always more of them than can be worked on at any given time, so I can understand the cold shoulder.
On the other hand I'm surprised some projects weren't able to clearly state their most pressing issues. I sure know what they are for #Friendica, and I would expect any other short-staffed FOSS (redundant, I know) project maintainer to know as well.
About the how to make it to the core team, the answer is sadly very simple: you have to do stuff. Take existing tasks on, suggest a new feature with at least an implementation stub to boot, fix existing bugs, take cleanup tasks o
... show moreGrouped answer to your last 5 tweets: Coming in hot in a project of which you don't know the unwritten philosophy is always risky. No formal team often also means no formal mission statement document you can base yourself on, so going blind you're bound to stub your little toe.
Additionally, unless you can implement it yourself, projects usually don't need additional suggestions, there's always more of them than can be worked on at any given time, so I can understand the cold shoulder.
On the other hand I'm surprised some projects weren't able to clearly state their most pressing issues. I sure know what they are for #Friendica, and I would expect any other short-staffed FOSS (redundant, I know) project maintainer to know as well.
About the how to make it to the core team, the answer is sadly very simple: you have to do stuff. Take existing tasks on, suggest a new feature with at least an implementation stub to boot, fix existing bugs, take cleanup tasks on. In practice you need very little communication with the other maintainers to become a member of the core team, you just need to work regularly on the project, as much on your own as possible.
Of course, to sustain this commitment, you better be using the project's product on a regular basis. This will also provide you with a user's perspective which will assuredly give you a good idea of the most pressing issues the project currently has.