Hey! Christopher Baines <[email protected]> writes: > I'll just reply to the bits I think are most important. Same!
> 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. > 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. To me, agreeing on the fundamental social structure seems to be a single issue, even though it holds various aspects. >> 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. > Maybe, but personally I'd prefer to structure GCDs in a way that they > can be read linearly. Me too! But when having somewhat circular definitions (maintainers granting commit access and team members deciding on the members of the maintainers collective) I had to make a choice. It is IMO nicer to read the proposal bottom-up than top-down (socially speaking). Thanks again! Enjoy your weekend! g
