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
for code:
preferrably create ticket at jira.neos.io (but not required)
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 jira.neos.io for organizing coding tasks after they are decided upon.
Challenges
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.
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 (PHP: rfc:scalar_type_hints_v5)
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.
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 (http://symfony.com/doc/current/contributing/code/patches.html#make-a-pull-request). 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
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.
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:
PRIVATE/ANONYMOUS vs PUBLIC/NAMED votes
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, …)