Accepting new feature specifications
Background: I wrote a feature specification for the account migration project. I want to get the feature delivered, but my work has been blocked by the fact that I didn't receive a feedback on the specification. Chances are that my work won't be accepted after I will have finished it without a prior approval of the spec. However the resources of the core team are limited and they distribute these resources by their own interests which may differ from the interests of the whole diaspora* community.
We need: a way to make it possible to accept new feature specifications (which are detailed technical descriptions of new functionality, perhaps with some implementation details) without a requirement of the core team involvement. Diaspora is a community governed project, so the power of decisions is in the hands of the community with voting as a main method of making decisions (with rules described here applied).
Proposal: We introduce a procedure of taking decisions on the feature specification acceptance based on loomio voting. Given we have a specification we want to accept. Then we start a loomio discussion in order to make a collective review of the specification and hear every opinion. When everyone have had a chance to say, but no earlier than two weeks, a community member may start a voting on that specification. The voting itself must go on no less than 2 weeks. If voting is finished with more yes than no+blocks then the specification is considered approved. However, even if the specification is approved by the latter rule, the core team members have a right to block the specification if at least 3 of the members of the core team voted block and gave a reasonable explanation of their point. If the specification is approved and not blocked, then the changes to the software that follow the specification must be accepted by the core team, no matter what is their own position on it. The results of voting may be revoked only by another voting with the usual rules applied.