| Interesting question. From my background in FOSS and open standards, one of the most common ways for possible changes to be made is the 'Request For Comments' (RFC). 1., therefore, is yes: many of the FOSS projects in involved in do write requirements specifications as part of an RFC process. 2., yes, I enjoy it. Not everyone does, but describing a proposal in great detail can clarify your own imagination of what it could be like, and can preempt inevitable questions. This saves everyone's time. 3., generally only long-term contributors, the 'shakers and movers' of a project. External or one-off contributors tend to suggest changes on issue trackers or chatrooms instead; this is partly because some don't want to make any commitment to shepherd the RFC through, but also because they don't necessarily have the background knowledge to know which questions to pre-emptively answer. 4., variable depending on the project. Small changes, that is, ones that don't affect much outside of their immediate context, don't usually have RFCs. It would be a waste of time for typo fixes, for instance. 5., I think this is very important: there should be a time limit on RFCs. The worst thing is when you have proposals that linger on for months or years and nobody quite knows how to move forward. Therefore, the leadership committee or whatever the responsible persons are called should give a clear yes-or-no answer after a fixed duration of public discussion. 7., absolutely, templates are expected. 8., "what other potential solutions have you considered?" is a classic question that every RFC submitter should answer. 9... well, nothing more really except good on you for taking technical change management seriously (a hard challenge, second only to cultural change management) and good luck :) |