Well, I think it is fair to say that there are some aspects of the GCD process that need adjustment!
I have some ideas I wanted to float to at least get some first takes on them before barging into formally proposing them... * several cycles of calling for consensus In all the discussion, sometimes it is not clear what issues are severe enough concerns to block consensus, and it is helpful to have one or more calls for consensus (e.g. the "deliberation" phase support/approve/disapprove), iterating until the issues that are blocking consensus are resolved or rejected. It is a long enough process that what might seem like a minor issue to one person might be important enough to stop the process to someone else... We should still have a limited number of passes to avoid the process dragging out indefinitely... but we should have formal process where we get a chance to resolve issues at some point before having to start over. The process should never end with an abrupt surprise, but should ideally be a gradual realization to everyone... * A serious concern is what blocks consensus, not the person It is way too easy to point to the person raising a blocking concern, but that is absolutely the worst thing you can do to build consensus. It should be focused on the issues raised as something to cooperatively resolve, not the individual personalities involved. To this end, I would like to propose that concerns are (eventually) raised as pull requests, patches or issues in some formalized process. I think this might make it possible to focus more on the specifics and a bit less on free-form dialogue... although free-form dialogue is an important part of the process, I think it does a poor job of tracking significant concerns which may get lost in the sheer quantity and volume of a discussion. I hope having formal pull requests would direct towards solving problems rather than simply talking about them, or in the worst case, blaming the messenger, which we really, really ought to avoid. * Every GCD as a separate project I envision each GCD as a new project for the initial draft, which is a reference from which to submit issues and/or pull requests, and also gives the ability to compare changes across revisions, see when a change was merged, etc. we can track the primary author(s) of a given change using git metadata, and use various *-by git commit traileer conventions. We can keep the whole change history archive as a reference, and possibly only merge the final result into the repository of official policies... * word choices I think the "deliberation" phase in the current GCD process is very confusing to me as a native English speaker, as it more commonly is a synonym for "discussion" rather than the tallying the final results of a decision. Inevitibly, social creatures that we are, we will want to discuss all the way through, but at some point it should refocus. I find "disapprove" to be far too weak of a word given the severe implications for the process. Again, with my native English speaker hat on, the difference between "disapprove" and "accept" is just a matter of degree, whereas the function "disapprove" holds in the process is much more severe than anyone's individual opinion. Not entirely sure of a better choice, but perhaps "reject" is more honest? Also using "I accept" "I support" "I disapprove" centers "I" more than the issues raised, which again, it should not be about the individual community members, but about the issues and concerns raised by the community. So, with some of these ideas I am admittedly trying to solve some social challenges with technology, but with a common denominator of technology we are already widely using in the project, I am hoping the specificity it might help the overall process. Or maybe it will just shift around some frustrations, who knows! :) live well, vagrant
signature.asc
Description: PGP signature
