Core devs: Decision making process

We've been growing our team and managing 10 individuals' thoughts and opinions is significantly more complicated than only 3 or 4. Our team's general decision making process has been to propose changes, discuss, and then if no one vetoes, go forward.

The core team has never been divided to the point of stalling out using this method, but with a growing team, I'm not convinced we should rely on that in the future. How does the other core devs and contributors feel about switching to a more formal voting process like PHP has for RFCs: https://wiki.php.net/rfc/automatic_property_initialization

This would also publicize the discussion around our decisions.

  • I like that - keeps the discussion out of emails which get missed/lost - and keeps a contextual history.

  • What are you envisioning beyond just having these discussions in the community/github rather than private email? I thought we already agreed to keep all future discussion on the community.

    Do all contributors get a vote? Or just the "core" team? How much should we consider "community" votes?

    Are we going to need to develop a platform for making these proposals?

  • Strawman: A vote is a GitHub issue (public comments welcome). To vote, edit the description adding a list item with a checkbox (yes = checked) and your name.

  • @Steve, I like that because then some code change can ultimately resolve the issue (much like the commit messages ticket right now).

  • What are you envisioning beyond just having these discussions in the community/github rather than private email? I thought we already agreed to keep all future discussion on the community.

    No changes to how we've already agreed to have discussions. It's an attempt to keep better records of the discussion and decisions if there's not a clear or immediate agreement.

    Do all contributors get a vote? Or just the "core" team? How much should we consider "community" votes?

    Core devs. I don't want design by committee.

    Strawman: A vote is a GitHub issue (public comments welcome). To vote, edit the description adding a list item with a checkbox (yes = checked) and your name.

     This could work and would keep us from having to develop anything for voting. My only concern is splintering discussion between this site and the vote issue.

  • We could just as easily do this by using the discussion forum on the community site, I guess. Core devs could simply edit the original discussion post to insert their vote.

  • If we do that, I would eventually like the discussion forums to natively support some kind of "resolution" for each discussion: approved, rejected, duplicate, resolved, etc. This is already on the feature request list so might just be a good option to support in general.

  • If we do that, I would eventually like the discussion forums to natively support some kind of "resolution" for each discussion: approved, rejected, duplicate, resolved, etc. This is already on the feature request list so might just be a good option to support in general.

    I like this idea. It does require some dev work on our side, but nothing extreme.

  • I like the simplicity of Steve's proposal as we already have many discussions on github. Any solution would do for me.

    I don't think we want to run this flow for every single pull request. I imagine we could do it for major api changes and features/changes that got "vetoed" (when we couldnt reach consensus easily).

    We probably should clarify what the "major" api change is.

  • Community voting sounds like a good idea. We'll get more freedom to add some of our own features. Dogfooding is also important.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.