20,741
edits
Help:Maintenance: Difference between revisions
Jump to navigation
Jump to search
→Promoting your ideas
(→Communication with other maintainers: added notice as per Conventions on discussion conclusions) |
|||
| Line 125: | Line 125: | ||
You've read this paper, you've done a few days of maintenance and still are convinced that your idea is worth to be discussed, and you're intending to support it. Great! Write about it at the Village Pump! Tell about it to some maintainer! Don't be afraid, it ''will'' be discussed. You might even find that it was already proposed, but that nobody ever put it in practice. If you think you were not understood, insist. If in the end you get no support, well, you have tried. That's [[how the FlightGear project works]]. | You've read this paper, you've done a few days of maintenance and still are convinced that your idea is worth to be discussed, and you're intending to support it. Great! Write about it at the Village Pump! Tell about it to some maintainer! Don't be afraid, it ''will'' be discussed. You might even find that it was already proposed, but that nobody ever put it in practice. If you think you were not understood, insist. If in the end you get no support, well, you have tried. That's [[how the FlightGear project works]]. | ||
{{Note|Please keep in mind that some of the best ideas recently implemented in FlightGear, or some of its infrastructure, still had a "shelf life" of 18-24 months - not because people wouldn't recognize good ideas, but simply because there's usually a very narrow "window of opportunity", where resources such as manpower, spare time (holidays), skills, expertise, experience and community support all align such that good ideas can actually be turned into new features without us having to drop something else. This is one of the most important aspects of how the FlightGear project works, and it is one of main show stoppers for newcomers: people expect their feedback to be acted upon immediately - unfortunately, we usually don't have the resources to act immediately, even if you should have an excellent idea. And lengthy discussions, especially heated ones, on the forum or the devel list aren't exactly helping either, because those take up precious time, too. It usually works better to file a feature request that can be reviewed by others, or even create a wiki article (e.g. RFC/RFD) so that others can keep an eye on it, i.e. to build up momentum over time. Sometimes, you may not get any feedback at all - this happens even to the most seasoned contributors, including core developers - it's not generally a sign that people dislike your idea, but that it would take up too much time to deal with it (keep in mind the [[Release Plan]]). Thus, timing really is important. As is building up "momentum" (support, skilled contributors). Honestly, we've had thousands of remarkably excellent ideas discussed over the years - but the reality is that ideas are worth a dime a dozen: actions count so much more, which is why a mediocre implementation beats an excellent idea. As contributors, we tend to use the terms ''hack'', ''workaround'' or ''prototype'' whenever we aren't exactly proud about our "short-term" solutions, which usually still end up being a part of the project for years. Actions speak louder than words... }} | {{Note|Please keep in mind that some of the best ideas recently implemented in FlightGear, or some of its infrastructure, still had a "shelf life" of 18-24 months - not because people wouldn't recognize good ideas, but simply because there's usually a very narrow "window of opportunity", where resources such as manpower, spare time (holidays), skills, expertise, experience and community support all align such that good ideas can actually be turned into new features without us having to drop something else. This is one of the most important aspects of how the FlightGear project works, and it is one of main show stoppers for newcomers: people expect their feedback to be acted upon immediately - unfortunately, we usually don't have the resources to act immediately, even if you should have an excellent idea. And lengthy discussions, especially heated ones, on the forum or the devel list aren't exactly helping either (no matter how you right you may really be!), because those take up precious time, too. | ||
It usually works better to file a feature request that can be reviewed by others, or even create a wiki article (e.g. RFC/RFD) so that others can keep an eye on it, i.e. to build up momentum over time. Sometimes, you may not get any feedback for months, or even none at all - this happens even to the most seasoned contributors, including core developers who've been developed for over a decade - it's not generally a sign that people dislike your idea, but that it would take up too much time to deal with it (keep in mind the [[Release Plan]]) at the time being. | |||
Thus, timing really is important. As is building up "momentum" (ideas, knowledge, tutorials, articles, support, skilled contributors). Honestly, we've had thousands of remarkably excellent ideas discussed over the years - but the reality is that ideas are worth a dime a dozen: actions count so much more, which is why a mediocre implementation beats an excellent idea. The perfect being the enemy of the good. As contributors, we tend to use the terms ''hack'', ''workaround'' or ''prototype'' whenever we aren't exactly proud about our "short-term" solutions, which usually still end up being a part of the project for years. Actions speak louder than words... | |||
Over time, you'll find that even the most seasoned contributors once were in your situation, and felt exactly like you, even if not even much more frustrated. As long-time contributors we're probably much more aware of FlightGear's ugly corners and issues, but we're trying to use this knowledge to motivate us, and to get involved in some way. There are quite a few areas that used to be unmaintained and underdeveloped for years - some of us have meanwhile become maintainers of those, not because we were asked to do so, but simply because we started contributing there. In other words: embrace the opportunity and be the change you want to see, even if that means filling a void - which may feel frustrating and discouraging at first, but at least you get to come up with your own terms that way. | |||
}} | |||
== References == | == References == | ||