Gabriel Wicki <[email protected]> writes: >> 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. > So far I have not read a single statement of disapproval over the > essence of this GCD. There is some doubt, but at least until somebody > steps forward and says something like "I will not be able to approve > this part of the proposal" I think we are on a good route.
What I'm trying to do here is suggest alternative approaches, rather than just saying "I disapprove". >> 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. > What specifics would you personally disapprove of in the current version > of the GCD? We are in the discussion phase: we can still delete stuff > and discuss them in future GCDs. Personally I don't see a pressing need to change the situation surrounding maintainers, so I disapprove of these changes in that it just seems to bring risk without any reward. I also don't get this from the text, the "Motivation" section doesn't set out why such significant changes are needed or what benefits they'll bring. > To me, agreeing on the fundamental social structure seems to be a single > issue, even though it holds various aspects. Right, but this is the point I'm disagreeing about. Even though you can view it as one topic, I think it's possible, and in this case desirable to try to make changes in smaller incremental steps. >>> 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. > As important as it may be: I don't think this is relevant to GCD007. > > >> "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. > I agree: that's why I drafted this proposal. What I was disagreeing with here was the framing of the GCD process as "properly" defining how to reach consensus.
signature.asc
Description: PGP signature
