Decision process
Light-weight decision process for project-related decisions in the gnucash project.
Mission Statement: The GnuCash core team will work to further the goal of the GnuCash project [1]: To provide free personal and small-business financial- accounting software, designed to be easy to use, yet powerful and flexible.
What decisions are concerned in this process: We distinguish "high impact" decisions and "low impact" decisions. The "high impact" decisions include authorization to spend large amounts of money (>=$1000 [2]), as well as partnerships, such as joining software conservancy, and also policy changes, or the delegation of decision tasks to particular individuals in order to have them act in the name of the project. The "low impact" decisions include adding new developers to the "core team" (explained below), or authorizations for smaller amounts of money (<$1000), or other decisions on which the project can change its mind easily with almost no losses.
Who is involved in this process: There is a "core team" that consists of people who contribute to the project significantly, be it as a developer, documentation writer, user support, or by other means. The core team members are subscribed to the (non-public) gnucash-core mailing list. Developers can join by asking for it or being proposed for it, and getting a "low impact" decision for confirmation (or by some alternative approval process on which the project has agreed upon). The minimum effort required for core team members is to agree or disagree with proposals in a reasonable way. Developers can leave by asking for it anytime. Developers whose participation ceases for more than 1 year can be asked by anyone of the core team whether they might want to leave the core team.
Actual decision process: Decisions are made as "informed consent" as described in sociocracy [3]. That is, one person proposes a decision ("let person X join the core team", or "pay the amount X to person Y for Z", or "authorize person X to do Y in the name of the project") and describes the proposal with sufficient information in a message to the gnucash-core mailing list. The proposal should be reasoned and argued toward the goals of the organization. During some period of time (defined below), the other core team members should comment on the proposal. Each core team member might speak up to express approval, or to express indifference, but must clearly speak up in case they have objections. Objections must be reasoned and argued and based on the ability of the objector to work productively toward the goals of the organization. As long as there are objections, the proposal is declined and the concerned core team members need to work together to clear out all paramount objections.
Once a proposal without objections is worked out, and enough core team members have replied, and no further objections arrive within the defined period of time [4], the proposal is approved.
On the other hand, if, after the requisite period not enough team-members have expressed approval or indifference, the proposal is rejected. A proposal needs to receive some minimum number of feedback in order to get accepted (in addition to work out objection resolutions), otherwise it does automatically die. It will be the one of the major responsibilities of any core team member to give some feedback, even if only stating indifference. On the other hand, it means the decisions will indeed be thought about by the majority of the core team.
In sociocracy, the person stating a proposal is expected to work closely with those people who have objections in order to resolve them. A common question would be: "How should the proposal be changed so that your objection is resolved?" The responsibility to come to an agreeable proposal is still on the original poster, who usually has a natural motivation to get the proposal approved. The good point is that the process shows which steps need to be taken so that objections are resolved: Not a vote counting, but instead concrete one-on-one discussions for resolving concrete objection reason.
Waiting period for "High impact" decisions: For high impact decisions, at least 75% of the core team need to give feedback. The period of time to wait for no further objections is 3 weeks, or alternatively feedback from 100% of the core team.
"Low impact" decisions: For low impact decisions, at least 50% of the core team need to give feedback. The period of time to wait for no further objections is 10 days.
(Note: As described in sociocracy [3], the process does not require a majority of votes here, but only a high enough feedback quota plus zero objections. Hence, as long as anyone has an reasoned objection, the decision is blocked and declined, but if the feedback varies only between indifference and agreement, the decision is agreed upon. This is one of the interesting peculiarities of the "informed consent" process in sociocracy. Nevertheless we must ensure there is enough feedback since we're only communicating by e- mail.)
Thanks for reading! I'll write about the proposed next steps to make an initial agreement on this process in another message.
[2] The threshold amount is meant as follows: Does the decision concern one or more payments totaling to this amount of money in the near future, e.g., as a single payment or as multiple payments over the next, say, 12 months.
[3] https://en.wikipedia.org/wiki/Sociocracy
[4] If a proposal received some objections, and the proposal is changed to clear out the objection, the waiting time counter is started from zero again once the changed proposal is sent to gnucash-core.
