Fr/Aide:Maintenance: Difference between revisions

Cependant, cela peut aussi parfois rendre les choses désordonnées. Il y a par exemple des cas où vous pourriez trouver des boucles, et celles-ci doivent être évitées. Ce n'est décidément pas un sujet facile, même choisir le nom d'une nouvelle catégorie n'est pas du tout anodin. Vous trouverez peut-être des directives sur la catégorisation sur [[w:Wikipedia:Categories, lists, and navigation templates|wikipedia:Wikipedia:Category#Category tree organization]]|, et une analyse approfondie des avantages et des inconvénients (et des alternatives) sur [[w:Wikipedia:Categories, lists, and navigation templates|Wikipedia:Categories]]. Ces choses, cependant, ne devraient être manipulées que lorsque vous avez une connaissance suffisante de l'ensemble du wiki, et après en avoir discuté avec d'autres responsables.

== Limitations of MediaWiki ==

=== Categorizing like tagging doesn't work ===

MediaWiki doesn't support (at least natively) the use of categories like tags, that is, the use of two or more unrelated categories that combine to make a particular one. This happens because ''when browsing'' the categories you can't combine them. So one should always use the most particular category that is possible, which might not be easy, given the convoluted nature of the category tree that even presents some huge loops.

An example: if an article is about creating airport layouts, it shouldn't be "tagged" with Scenery and Development (they're both into [[:Category:FlightGear]]), but classified into Scenery enhancement (which is another way of saying "scenery development").

=== Editing categories is cumbersome ===

There is no other manual way to edit the category tree (e.g. moving articles, renaming categories...) than ''editing one by one each categorized page'', be it an article or a category page (and thus, the category itself). To some extent, such work can be done by bots (automated software editors), but they're pretty dangerous and their usage must be very carefully planned and tested with maintainers and admins.

== Promoting your ideas ==

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 (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 ==

[[Category:Help]]