Gabriel Wicki <[email protected]> writes: > Hey Chris! > > What a message! I am weirdly happy, because, you know, as soon as > contradictions emerge, we get a little bit closeer towards what we > really want/what is the actual issue (: > > > Please excuse that I shuffled the order of your statements to point the > contradiction out (emphasis by me) and addressing your raised points by > decreasing importance:
That fine, to try and focus down a bit, I'll just reply to the bits I think are most important. >> To me the GCDs seem like a process and record relating to a decision >> made at a point in time. This is very different from the manual which is >> a living document which can change constantly. >> >> To me this has implications on the decisions that should be made through >> GCDs, at least in my view it would be good to explicitly say if >> decisions that are made are just for that instance, or an ongoing >> commitment. >> >> For me it would make more sense for say a GCD to decide to change > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> something major in the manual, rather than attempt to move stuff from > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> the manual to the GCD. At least while there's this uncertainty about how >> accepted GCDs should be treated going forward. > > And another passage by you (again: emphasis by me): >> > Why, though? Are "maintainers" not a (special) sub-group (team) of our >> > project? To me it would feel wrong to specify everything but the >> > maintainers here... >> >> Mostly because it's such a major change and decision. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> I get the intention about trying to set out something comprehensive, but >> that doesn't mean it's right or helpful to change so much at the same >> time. > So... is there something to change in a major way in this GCD or is > there not? Damn those German philosphers with their dialectics! :P > > > Seriously, though: There must be consenus that accepted GCDs are not > rules set in stone. We currently lack a (formalized) process on how to > address changes or appendices to GCDs. But we also don't need that. > This project has grown naturally—technically as well as socially—so why > would we not let things happen, observe how they come to be and only > prune what is necessary once we feel the need? GCD007 proposes such an > attempt. But yeah, maybe GCD's are too serious for experiments. It's not particularly clear to me what you're asking here. The approach I'm suggesting in the bit you've first highlighted is to have one or more GCDs that make changes in and around teams, but to view the GCD itself as a description of that decision, and the effect of the GCD being accepted is to update the manual and whatever else needs updating accordingly. To me this is much more in line with the existing GCDs and how I imagine the process going forward. The second point is that I'm not against discussing maintainers, but I don't see the necessity of trying to have everything in one discussion. I feel it would be easier for people to contribute to the discussions if they were more focused and it feels like the topic of maintainers can be split out, and is substantitive enough to have it's own discussion/GCD. >> I would argue that we do have processes to build consensus outside of >> the GCD process, the main one being patch review. I think >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48696 is a reasonable >> example of this in the context of roles and responsibilities. > This is a great example! Of course there (probably always) was > consensus in this project, but only with GCD001 it was properly defined > how to reach it and (more importantly for GCD007) by whom. I think this is something we disagree on, and it's seems quite important. "but only with GCD001 it was properly defined how to reach it" I don't see the GCD process as any more proper or authoritative than other processes to reach consensus, e.g. patch review. It's intended to work in addition to those processes to provide more structure and draw the attention of more people when that is helpful. > GCD001 somehow elevated team members to decision makers. Which IMO is > great! The agreement on GCD001 meant that we, as the big project we > are, care about the opinion of our team members. And—at least how I > have handled memberships to my teams so far—**anyone** can become one at > ease. "elevated" is rather vague, but I don't think that was the intention. I see the change more as GCD001 added restrictions on to community members who aren't in any teams, since while they're encouraged to participate in the discussion period, the deliberation is more limited. >> Yep, I'm just reading it through top to bottom, but I think this a >> reasonable approach. > Well, if you had read the whole thing and only later commented, you > might have answered some of your questions yourself ;) Or maybe refined > the questions. Maybe, but personally I'd prefer to structure GCDs in a way that they can be read linearly.
signature.asc
Description: PGP signature
