Proposal: The Decision Making / RFC Process

Hey everybody,

This posting (created together with @bwaidelich) sums up the meeting we had at the Neos Code Sprint in Nürnberg with @bwaidelich, @kdambekalns, @sebastian, @aertmann, @christianm and several other code-sprint contributors.

All the best,
Bastian and Sebastian

This is a Wiki-Posting, so if you want to adjust the posting, feel free to do that.

Problems we want to solve

  • Making decisions and the decision process visible and persistent (previous and ongoing) – inside the team and for all community members
  • Making the decision process transparent
  • Make it possible for non-team members to join discussions before a final voting
  • A RFC process that allows people to easily work together on a concept before deciding upon it
  • Reducing the likelihood of “half-baked” solutions
  • Make sure nobody (in the team) misses important decisions

Types of decisions

  • Organizational
  • e.g. „establish upper limit of team members?“
  • Infrastructure
  • e.g. „Evaluating slack for communication“
  • Brand
  • e.g. „New Neos logo“
  • Technical (Code)
  • e.g. „Change CGL rules"
  • Financial / Budget
    • e.g. “what do we want to use Budget for”?

No matter which decision type we take, we suggest to take the decision applying (more or less) the same guidelines (outlined below).

Solution Idea

For each decision, we propose to “think” in three categories; each with their individual “decision process”. Keep in mind that this is not rigid, but rather a guideline.

  • small: easily reversible, low impact

  • medium: reversible, medium impact

    • create concept / mini RFC in discourse
    • discussions+decision happens on discourse!
    • after decision, for code: create ticket(s) for tracking implementation progress
  • large: hard to revert, high impact

    • like with “medium”, but requires a quorum of team members to agree

Tool Usage Proposal

Use Slack for quick questions, synchronous / small polls. Somebody who does not read Slack should not miss any relevant discussion! -> If discussions get bigger, start moving to discourse.

Use Discourse for discussion, decisionmaking, project planning and organization.

Use for organizing coding tasks after they are decided upon.


  • avoid needless Bureaucracy
  • avoid stagnation due to abstaining of team members
  • conflict of traceability/transparency and bias
  • possibly higher entry barrier for contributors; e.g. bigger patches with no RFC will be rejected. On the other hand, it might also lower the barrier because of more clear structure.

Still open questions

  • PRIVATE or NOT PRIVATE voting? (depends on the topic possibly)
  • LIMITED TO TEAM MEMBERS vs OPEN to everybody

Proposed Next Steps

  • come up with some more guidance criteria on how to decide between small, medium, large
  • come up with an “RFC-Template” which you can copy and fill in
  • please read through this and comment/tweak
  • as soon as a general consensus throughout the team seems to emerge, we’ll do a voting period about this process.

To avoid stagnation, I think timeboxed voting period is an important point.

Personally, I love the RFC guidelines of PHP (

  • First discussion (like slack) to get basic feedback from the community and team
  • Second start an RFC “In Draft”,
  • Third put the RFC in “Under discussion” be responsible to answer all question, complete the RFC (can be timeboxed, with a minimum, like 1-2 week)
  • Maybe this In Draft period can be used to decide the severity (S, M, L, XL, XXL)
  • When ready ask team member to open voting period for the RFC (in my POV, it’s important to have a peer review of the RFC by core team member to be sure that the feature can fit in the core, or external package, …)

PHP use RFC karma point, a user without enought point is not able to write an RFC, but he can try to found people with enough karma to handle the RFC. Maybe a good idea to avoid RFC overflow (we don’t have a lots of resource to handle a lots of RFC, so it could by a bad signal to have tons of open RFCs)

Based on the Munich sprint discussion, we need to have a decision making as cristal clear has possible. Voting can require an invitation (for some really specific case), but the discussion and voting result must be public and the name of the voter must also be public (responsibility and voting “owernship” is important), like the voting table to PHP (

@dfeyer Thanks for your feedback!

Yes, I think they’re a good fit for the technical part (sub projects, major refactorings/features, …)

That’s also a nice idea - but maybe it’s a bit “overengineered” for our case, at least for the beginning. Let’s see if we really face the problem of too many RFCs first

I definitely agree to the first part: voting results must be public. Not so sure about the 2nd part though. Imagine a voting about a new member for example, people might be biased if they’re not allowed to vote anonymously.
Anyways this was more about how we could achieve votings that only a certain group (team members) can vote upon.

@all some more feedback would be useful!

I assume the private / not private voting is about being able to vote publicly or invite only? If so I agree to it being dependant on the topic. We wouldn’t easily make a vote around team members publicly open for example. And in line with that example I also agree to have voters public by default, but the possibility make them anonymous in the public report.

I share the feeling that we might end up with an RFC overflow rather sooner than later, so the karma points sound tempting. But starting with that from the beginning might indeed be a bit too much.

Regarding the size decision making I tend to stick to how I used a similar scoring before in IT support. We had 2 factors being the number of people affected by an incident and the urgency it had for that employee (how many hours he could survive without the issue being fixed). We gave a score for both of these factors, multiplied them and based on the outcome the priority was defined.
Symfony does something similar for pull requests, they’ve a list of questions you’ve to answer ( To me it seems those questions are meant to give an idea of the impact of the change. Maybe we could come up with a list of qualifications? Like for example:

  • Introduces new functionality
  • Changes behavior
  • Changes API
  • Breaks BC
  • Has nothing to do with code at all
  • Has enormous political consequences
  • Could possible start a war
  • … and so on :wink:

Furthermore I look forward to having this all in place and just get experience with it in practice because I’m convinced it will be a better guidance, also for contributors.


We definitively need this one :wink:

you mean like deciding about whether to adapt a PSR ruleset? :smiley:

1 Like

Greetings from the Neos Sprint in Frankfurt!

Yesterday we formed a small group to (re)discuss the “Decision Making” topic.
We started by going through this very draft and adding some ideas & fine-tuning.
This morning we quickly presented the outcome and the general feedback was quite positive. Also the concept goes quite well with the planned project restructurings.

So I think we’re ready to go ahead and should start writing down the initial guidelines.
There are still a few questions:

  • in general we should try to keep everything transparent and public
  • I’d suggest to start with public votings only. If we come across decisions that require privacy/anonymity (e.g. security feature/personal matters) we can redefine that process
  • LIMITED TO TEAM MEMBERS vs OPEN to everybody
  • still to be defined, probably it will depend on the impact of the decision. With the new team structure in place small and medium decisions can probably be voted upon within the team. large decisions within all teams and/or possibly with public participation.

Some new opinions from the sprint:

  • We have the feeling that we should start off with pretty strict rules at least for medium and large decisions (ask in slack, create discourse post, timeboxed discussion phase, timeboxed voting phase) and to adjust/relax the processes if they don’t work out
  • Roles of the new team structure could be incorporated in the process (just a rough idea):
  • synchronizers* should keep track of new suggestions in order to help newcomers and in order to prevent “repeating history”
  • prioritizers* can pull in closed decisions into their team as projects
  • elders* should escalate “stalled decisions” (e.g. close RFCs after inactivity for x months, …)

* = those are work titles

1 Like

hi basti,
maybe this different approaches to come to decisions might help the discussion…
cheers gina