Planning a new extension
This is an essay. It expresses the opinions and ideas of some mediawiki.org users, but may not have wide support. Feel free to update this page as needed, or use the discussion page to propose major changes. |
Planning a new extension can consist of writing a proposal in the mainspace of MediaWiki.org or in your own userspace. If it is a short proposal, you could just submit a Phabricator task under MediaWiki-extension-requests; you may wish to check the list of those already filed).
Some people scoff at the idea of posting a proposal and say "Just implement your idea. Don't pussyfoot around; DO IT!" The idea is that debating ideas is only necessary when one is planning a potentially controversial change to the core. Also, it takes more effort to code than to write a proposal, so making the effort shows that you've demonstrated some commitment to the idea, enough to at least write something that works.
In some parts of life, it's helpful to propose ideas and get feedback before acting; but programming can be different. It often becomes evident, during implementation, that a scheme that seemed so good in a proposal is difficult to actually make work, especially given that one has to work with, or alongside, the existing codebase. New developers can pretty much expect that a lot of their code may need to be rewritten, because they may write poorly designed code or inadvertently reinvent the wheel due to their unfamiliarity with what is already out there.
For these very reasons, new developers may feel unsure of themselves and want to solicit feedback before going forward with implementation. One problem with this is that often, no one else will care about the proposal enough to read it and comment. People seem more willing to review code that has already been written than to provide input on an idea that is, for the time being, manifested only as an essay, especially if it's a long essay; but even code review can be hard to come by sometimes.
On the other hand, the exercise of organizing your thoughts enough to put them into writing can sometimes be a useful form of rubber duck debugging. Even if you never write the code, if you happen to forget why you hesitated, you can look back at the document of your qualms and remind yourself of where your thinking left off, rather than having to think through the whole thing again. Or you may remember it better just from having written it. It's also possible that if you look back at your thinking six months later, you may change your mind and decide to implement the idea after all.
People who are able to envision and plan their idea without the need to write it down first may view the planning document stage as a waste of time and possibly even procrastinatory. Such documents may even be viewed as off-topic essays; people may question the proposer's willingness to ever implement his idea, because sometimes people write down ideas as a substitute for, rather than as an aid to, writing actual code.
One option, if one's idea is so complicated that it's hard to mentally keep track of everything involved, is to meet in the middle (between English and PHP/SQL/whatever) and write some pseudocode. You can also, as you're programming, document implementation ideas you are rejecting, abandoning, or putting off till later, and explaining the ideas you did go with. It can sometimes be useful later to look back at, especially if there's a pause in your development efforts, during which you forget what you were doing.