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 (https://wiki.php.net/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
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, …)