Accepting new feature specifications

Governance
1

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.

Opinions?

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

Sounds like a fair idea. But there was always everybody welcome to give feedback to specs (the same as everybody is welcome to review PRs). So it is not only a core-team thing.

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.

The block thing is important to me here. I think if there is even only one block with a reasonable explanation it needs at least additional discussions. And I also think that everybody can block, if there is a reasonable explanation, not only core team. A spec shouldn’t be approved only because there are many “yes” votes from people who only want the features as fast as possible and possibly they didn’t even read the spec.

3

Agreed with everything said by SuperTux, including the blocker.

4

It’s a good idea to think about how to make reviewing specs a wider process, and to take load off the small number of core and community members who do this important work. However, I think if you are going to use Loomio to do this, we would have to create a special ‘group’ within Loonio and restrict membership of that group to people who have demonstrated that they have sufficient knowledge of the code, or at least of relevant areas/types of coding. Otherwise

A spec shouldn’t be approved only because there are many “yes” votes from people who only want the features as fast as possible and possibly they didn’t even read the spec.

will be a problem.

Another means will be simply to publicise spec within Diaspora, requesting people with the requisite knowledge to review it carefully and comment. I think refining spec through comments is more efficient way of gaining acceptance than voting yes/no until everyone votes yes. We could perhaps use the Diaspora HQ account to publicise such specs.