Message ID | 878rgga1qv.fsf@inria.fr |
---|---|
State | New |
Headers | show |
Series | [bug#61894,RFC] Team approval for patches | expand |
Ludovic Courtès <ludo@gnu.org> writes: > Currently teams are described mostly as pools of people who can mentor > contributors in a particular area and who can review patches in that > area. My proposal is to give teams formal approval power over changes > to code in their area. > > This is sorta happening already, but informally: if a non-committer > sends a patch, someone from the team eventually “approves” it by pushing > it. Within a team, the situation is different: people usually discuss > changes, and the submitter (also committer) eventually pushes them; > sometimes, the submitter pushes changes without getting approval (or > feedback) from others on the team. > > With the proposed policy, members of a team would also have to review > and approve each other’s work. Formal approval means getting an > explicit “LGTM” (or similar) from at least one other team member. > > This is similar to the review thresholds found on GitLab & co., where > project admins can specify a minimum number of approvals required before > a change is marked as ready. I think it avoids the unavoidable > misunderstandings that can arise in a growing group and help pacify > day-to-day collaboration. I guess I'm still a team sceptic, I think the idea is interesting and I have added myself as a member of some teams. But the main impact on me so far is that I've just been getting some unwanted personal email, messages that previously wouldn't have landed in my inbox have been doing so. Regarding this change specifically though, I'm unclear how it would impact the things I push for others. I pushed some patches today, would this mean that I'd have to look at what team/teams are involved (according to /etc/teams.scm.in) for each commit/series, and then either continue if I'm a member of that team, or skip it if I'm not? If I'm going to not be pushing stuff I would have previously pushed because I'm not in the relevant teams, maybe I should just add myself to every team? I guess this is not a serious question, but I'm more making the point that if teams become a formal part of patch review, then some formalities over membership of a team is probably a prerequsite. As a point of clarification, if a patch or series touches files that fall within the scope of several teams, am I correct in saying that this change would require approval from all teams? Thanks, Chris
On Wed, 01 Mar 2023 17:15:26 +0000 Christopher Baines <mail@cbaines.net> wrote: > I guess I'm still a team sceptic, I think the idea is interesting and > I have added myself as a member of some teams. But the main impact on > me so far is that I've just been getting some unwanted personal email, > messages that previously wouldn't have landed in my inbox have been > doing so. > > Regarding this change specifically though, I'm unclear how it would > impact the things I push for others. I pushed some patches today, > would this mean that I'd have to look at what team/teams are involved > (according to /etc/teams.scm.in) for each commit/series, and then > either continue if I'm a member of that team, or skip it if I'm not? I'm on Chris' side. We need less burden to review/push, instead of more formal rules/obligations. Speaking about me, I'm in the Java team, where my knowledge is best, but in the past I also "wildered" in the Python and Ruby areas. I think I always tried to be cautious with my reviews though: If I saw it was just a simple version update with no dependency changes, and it builds/runs afterwards, I gave an OK and/or pushed it, although I'm not the super-expert. If it was too hot for me, I left my fingers from it or asked a known expert for help. "Teams" are a nice hint (for example, adding a tag to the bug entry), but I wouldn't make it too formal. Björn
Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes: > On Wed, 01 Mar 2023 17:15:26 +0000 > Christopher Baines <mail@cbaines.net> wrote: > >> I guess I'm still a team sceptic, I think the idea is interesting and >> I have added myself as a member of some teams. But the main impact on >> me so far is that I've just been getting some unwanted personal email, >> messages that previously wouldn't have landed in my inbox have been >> doing so. >> >> Regarding this change specifically though, I'm unclear how it would >> impact the things I push for others. I pushed some patches today, >> would this mean that I'd have to look at what team/teams are involved >> (according to /etc/teams.scm.in) for each commit/series, and then >> either continue if I'm a member of that team, or skip it if I'm not? > > I'm on Chris' side. We need less burden to review/push, instead of more > formal rules/obligations. Identifying when you share someone's views in a discussion can be helpful, but I don't see how taking sides is, we should all be on the same side. Even if this is what you meant, trying to frame things constructively is always helpful.
Hi, On Wed, Mar 1, 2023 at 9:31 AM Christopher Baines <mail@cbaines.net> wrote: > > I'm unclear how it would > impact the things I push for others. I pushed some patches today, would > this mean that I'd have to look at what team/teams are involved > (according to /etc/teams.scm.in) for each commit/series, and then either > continue if I'm a member of that team, or skip it if I'm not? Perhaps a compromise would be to ask committers to get a second opinion from another committer whenever they feel it is necessary. A committer who is confident enough, however, would be encouraged to sidestep the restriction. This guidance would gently bump the perceived penalty for a misstep, because ignorance was then part of the mix when an error occurred. The second person will often be from an affected team, but sometimes they won't. That would only need to be revisited when there was a problem. Otherwise, it was water under the bridge. A softer guidance would also allow the project to experiment gradually with greater checks and balances. After some time, the committers would be able to weigh—both individually as well as collectively—whether the additional rules actually provided the benefits they were designed to produce. Kind regards Felix Lechner
Hi Chris, Christopher Baines <mail@cbaines.net> skribis: > I guess I'm still a team sceptic, I think the idea is interesting and I > have added myself as a member of some teams. But the main impact on me > so far is that I've just been getting some unwanted personal email, > messages that previously wouldn't have landed in my inbox have been > doing so. Same for me (took me a while to understand why I was suddenly Cc’d on some many patches. :-)) I’m not sure how to improve on that. > Regarding this change specifically though, I'm unclear how it would > impact the things I push for others. I pushed some patches today, would > this mean that I'd have to look at what team/teams are involved > (according to /etc/teams.scm.in) for each commit/series, and then either > continue if I'm a member of that team, or skip it if I'm not? > > If I'm going to not be pushing stuff I would have previously pushed > because I'm not in the relevant teams, maybe I should just add myself to > every team? I guess this is not a serious question, but I'm more making > the point that if teams become a formal part of patch review, then some > formalities over membership of a team is probably a prerequsite. > > As a point of clarification, if a patch or series touches files that > fall within the scope of several teams, am I correct in saying that this > change would require approval from all teams? Good questions. For teams like ‘core’ or ‘home’, there should be no overlap, so it’s quite easy to see who’s in charge. Teams related to packages are more likely to overlap, and it’s also an area where we generally want more flexibility. The example you give—pushing patches even though you’re not on the corresponding team(s)—is something we’d still want to allow most of the time. There seems to be different requirements depending on teams. I’d like more coordination and clearer responsibilities for subsystems (guix/*, gnu/{services,system,build}/*, etc.) and key packages/tools (Python, ocaml-build-system, etc.). For “random packages”, I’m fine with the status quo. WDYT? Thanks, Ludo’.
Hello, in the current situation I think the suggestion is putting the horse before the cart. In a first step before adding policy, we should make the teams functional. While working on core-updates, I have been realising we are already spread too thin: Some important languages have teams with one or two members, who would effectively become bottlenecks. Other software has no team (Qt/KDE). All in all, I also think we have too few committers. Adding policy might completely stall the project... If for every trivial update of a Python package we need not only submit a patch to the bugtracker, wait for QA, get back to the patch, resign it, push it and close the bug, but additionally wait for one of the two Python team members to have a look at it (or let an additional week pass), incentives to participate will tend to zero. Your suggested policy can help against commits of too bad quality; but I do not think this is our problem, our problem is rather a lack of fast progress. So I think we need to add committers, add committers to teams, encourage teams to engage in work, and if everything works smoothly, maybe add policy. Andreas
Hi, tl;dr: If you want to expand the list of committers rapidly, would it make sense to have a sand-box repo for new committers which trusted committers could channel cherry-picks from? Pick your bugaboo, but I consider plausible that some volunteering committers are there on paid job assignment serving some agenda which you can't easily discover. Well, that can be good and normal with FLOSS-enlightened emplayers, but one can imagine not-so-benevolent assignments... (pick your concept of benevolence :) On +2023-03-02 12:04:44 +0100, Andreas Enge wrote: > Hello, > > in the current situation I think the suggestion is putting the horse before > the cart. In a first step before adding policy, we should make the teams > functional. While working on core-updates, I have been realising we are > already spread too thin: Some important languages have teams with one or > two members, who would effectively become bottlenecks. Other software has > no team (Qt/KDE). All in all, I also think we have too few committers. > Adding policy might completely stall the project... > > If for every trivial update of a Python package we need not only submit a > patch to the bugtracker, wait for QA, get back to the patch, resign it, > push it and close the bug, but additionally wait for one of the two Python > team members to have a look at it (or let an additional week pass), > incentives to participate will tend to zero. > > Your suggested policy can help against commits of too bad quality; but I > do not think this is our problem, our problem is rather a lack of fast > progress. > > So I think we need to add committers, add committers to teams, encourage > teams to engage in work, and if everything works smoothly, maybe add policy. > > Andreas > > -- Regards, Bengt Richter
Andreas Enge <andreas@enge.fr> writes: > Hello, > > in the current situation I think the suggestion is putting the horse before > the cart. In a first step before adding policy, we should make the teams > functional. I find debian have various teams, and each team has a page for packages status: https://tracker.debian.org/teams/debian-multimedia/ If we want more functional/formol teams, I think we need more tools like this.
Hi Ludovic, Ludovic Courtès <ludo@gnu.org> writes: > Hello Guix! > > The project has been steadily gaining new contributors, which is great, > and I think we need to adjust our processes accordingly. > > Currently teams are described mostly as pools of people who can mentor > contributors in a particular area and who can review patches in that > area. My proposal is to give teams formal approval power over changes > to code in their area. > > This is sorta happening already, but informally: if a non-committer > sends a patch, someone from the team eventually “approves” it by pushing > it. Within a team, the situation is different: people usually discuss > changes, and the submitter (also committer) eventually pushes them; > sometimes, the submitter pushes changes without getting approval (or > feedback) from others on the team. > > With the proposed policy, members of a team would also have to review > and approve each other’s work. Formal approval means getting an > explicit “LGTM” (or similar) from at least one other team member. > > This is similar to the review thresholds found on GitLab & co., where > project admins can specify a minimum number of approvals required before > a change is marked as ready. I think it avoids the unavoidable > misunderstandings that can arise in a growing group and help pacify > day-to-day collaboration. > > Below is a suggested change. > > What do people think? > > Ludo’. It sounds reasonable and a good change "on paper", but in practice I think it may be too soon to formalize teams that way. Teams are a nascent concept which hasn't reached a point we can rely on it, in my opinion. We are still ironing out kinks in the tools [0] :-). I'd prefer we stay as nimble/agile as we can and maximize the potential of our large committers pool for now, at the expense of sometimes having to retroactively discussing/fixing up or reverting some change that wasn't up to par, that could have possibly been caught by a more focused team. [0] https://issues.guix.gnu.org/58813
Hi, Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > It sounds reasonable and a good change "on paper", but in practice I > think it may be too soon to formalize teams that way. Teams are a > nascent concept which hasn't reached a point we can rely on it, in my > opinion. We are still ironing out kinks in the tools [0] :-). I'd > prefer we stay as nimble/agile as we can and maximize the potential of > our large committers pool for now, at the expense of sometimes having to > retroactively discussing/fixing up or reverting some change that wasn't > up to par, that could have possibly been caught by a more focused team. I think formalizing collaboration would be the way to “maximize the potential of our large committer pool”: by having clear rules, we make it easier to work together, not harder. Retroactively fixing, reverting, or discussing often causes unnecessary friction and puts pressure on the collective. Discussion should always happen before the fact. We’ve reached the point where the code base is large and the experiences of individual contributors vary. To cope with that, I think we need to communicate and coordinate more to have a shared understanding of the code, of our goals, of our needs and expectations. We can no longer rely on implicitness and the idea that silence is consent. This proposal is one possible step in that direction, but I’m open to other approaches. Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi Chris, > > Christopher Baines <mail@cbaines.net> skribis: > >> Regarding this change specifically though, I'm unclear how it would >> impact the things I push for others. I pushed some patches today, would >> this mean that I'd have to look at what team/teams are involved >> (according to /etc/teams.scm.in) for each commit/series, and then either >> continue if I'm a member of that team, or skip it if I'm not? >> >> If I'm going to not be pushing stuff I would have previously pushed >> because I'm not in the relevant teams, maybe I should just add myself to >> every team? I guess this is not a serious question, but I'm more making >> the point that if teams become a formal part of patch review, then some >> formalities over membership of a team is probably a prerequsite. >> > [...] > > Good questions. > > For teams like ‘core’ or ‘home’, there should be no overlap, so it’s > quite easy to see who’s in charge. > [...] > For “random packages”, I’m fine with the status quo. Hello, I'd like to know if I'm working fine according to the status quo.. I usually push patches for others who don't have commit access, while most packages don't have a team at all, and some with me as the only team member. Should I wait for another commiter's approvol under this new policy or can I push "random packages" (eg: jwm) solo under the status quo? For packages I as the only team member (eg: fcitx), should I looking for another commiter for other's patches and my patches? Thank you!
Hello, Am Tue, Mar 07, 2023 at 09:53:29AM +0800 schrieb 宋文武: > I usually push patches for others who don't have commit access, while > most packages don't have a team at all, and some with me as the only > team member. > Should I wait for another commiter's approvol under this new policy or > can I push "random packages" (eg: jwm) solo under the status quo? For > packages I as the only team member (eg: fcitx), should I looking for > another commiter for other's patches and my patches? under the current policy, what you do is fine and very welcome. Under the new policy, it would not be (if I remember correctly, there is a one week waiting policy, after which one could push nevertheless). So while the idea is good in principle, I think we would have to make sure that first: 1) Every current and potential new package is covered by a team. 2) Every team has at least 3 members, better yet 4 or 5. 3 members would make it possible that even if one of them is on vacation or otherwise busy a patch could be pushed without this additional one week if the other 2 agree. And I also think we then need 3) more tooling; maybe a mailing list for each team? A file that contains the link between source code files and teams, and a script around "git send-email" that automatically puts into cc the corresponding team when submitting a patch? And the feature branches with QA on cuirass or the Guix Build Coordinator that we talked about at the Guix Days. I think our main problem right now is lack of committers and/or contributors. While looking at core-updates, I was surprised how outdated some of our packages are (around Qt, KDE and Python, for instance; I suppose it depends a lot on the field), in particular for a rolling release distro. (For Qt@5, we were at a release from June 2022, and there had been more recent releases in September, October and January; it would be nice to have a working team preparing a feature branch in a timely fashion after each release.) There are currently 48 committers, and not all of them are active. I think this is just not enough for 20000 packages. Andreas
Hi, On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote: > 1) Every current and potential new package is covered by a team. > 2) Every team has at least 3 members, better yet 4 or 5. > 3 members would make it possible that even if one of them is on vacation > or otherwise busy a patch could be pushed without this additional one > week if the other 2 agree. It would help if being committer implies appearing at least in one team, no? Currently in etc/teams.scm.in, I count 26 members and 20 are committers over the 48 ones. No blame. :-) Somehow, we have a bootstrap problem – bootstrap is everywhere. ;-) From my understanding, Ludo’s proposal is about some structure of how “teams“ would work and that structure would help in constituting “teams”. One way for bootstrapping. From my understanding, the other approach somehow proposed between the lines in this thread would be to first constitute “teams” and then document how they work. The other way for bootstrapping. While I am not convinced by Ludo’s patch, I think the approach to document first how we would like the “teams” would work is better for bootstrapping them. Cheers, simon
Hi, On Tue, Mar 7, 2023 at 2:37 AM Andreas Enge <andreas@enge.fr> wrote: > > And the feature branches with > QA on cuirass or the Guix Build Coordinator that we talked about at the > Guix Days. For what it's worth, someone turned one of my patch sets into a proof-of-concept for feature branches. You can follow the progress via the original patch, [1] the feature branch, [2] or the resulting CI job set. [3] [1] https://issues.guix.gnu.org/61989 [2] https://qa.guix.gnu.org/issue/61989 [3] https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-go-updates > There are currently 48 committers, and not all of them are active. > I think this is just not enough for 20000 packages. If a brief comparison is permitted, Debian maintains 35,000 source packages with about a thousand voting members (aka Debian Developers) as well as another thousand or so contributors. My estimate is that about a third of all those people are active. On a per-package basis, that's about fifty source packages per contributor there. For Guix, I do not know how many committers are active or how many people contribute without commit privileges, but assuming two hundred active contributors altogether, I arrive at a guesstimate of about 100 packages per contributor for us. Packaging in Guix is much simpler, however, and our collective approach and care also reduce the pressure to be perfect. (In Guix, the "perfect" sentiment only survives in the formattin of commit messages.) Debian's celebrity status among software distributions also attracts a lot of people. As a side note, the growth of a group can lead to greater social tensions and a proliferation of outside politics. Given the excellent stewardship in Guix to date and the technical possibilities of automatic patch approval, I am therefore not necessarily in favor of growing the contributor base at all costs. We really have something special in Guix. Thank you all for your hard work and mutual friendship! Kind regards, Felix Lechner
Hi Simon, Simon Tournier <zimon.toutoune@gmail.com> writes: > Hi, > > On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote: > >> 1) Every current and potential new package is covered by a team. >> 2) Every team has at least 3 members, better yet 4 or 5. >> 3 members would make it possible that even if one of them is on vacation >> or otherwise busy a patch could be pushed without this additional one >> week if the other 2 agree. > > It would help if being committer implies appearing at least in one team, > no? > > Currently in etc/teams.scm.in, I count 26 members and 20 are committers > over the 48 ones. No blame. :-) If most committers end up being team members, aren't we back to where we currently stand? It seems the original motivation here is to add some extra control/guards against undesirable commits landing in the core of Guix. If a committer that previously landed such commits joined the core team (e.g., myself), it seems to me the situation would be little changed: 1. Our pool of reviewers would likely continue to be spread too thin. 2. The 2 weeks time window would quickly slip, even with a team looking at a more focused backlog, or the reviews would only be of the kind "I think that's not what we want" without more time or energy to offer the kind of concrete insights that can be turned into action for the submitter. 3. The team member might be tempted to take their chance and merge their change with little to no feedback, or feedback they perceived insufficient or not actionable enough to justify keeping their submission in limbo for longer. I think the main problem we have is social, not organizational. There's little incentive to jump into the laborious review process compared to hack on something we like in our free time. We need to promote and value review work more, without making it feel like a compulsory chore. That's a great challenge to solve for a project that's driven by volunteers. I'll venture a suggestion to explore: adding enticements to review (some playful guidelines such as "while waiting for your 2 weeks review period, please try to review twice as many other submissions that have been patiently waiting on the patches tracker :-)", or some stats crunched and advertised periodically to guix-devel or even our to our blog about our top reviewers, etc.).
I don't have a strong opinion one way or the other about whether we should formalize the review process. The status quo isn't working well, so I'm in favor of trying something. On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote: > I think the main problem we have is social, not organizational. There's > little incentive to jump into the laborious review process compared to > hack on something we like in our free time. We need to promote and > value review work more, without making it feel like a compulsory chore. > That's a great challenge to solve for a project that's driven by > volunteers. However, I agree with this point wholeheartedly. We really need to ask ourselves, why would anyone review patches? It's a lot of work, often thankless, and unfortunately sometimes unpleasant. > I'll venture a suggestion to explore: adding enticements to review (some > playful guidelines such as "while waiting for your 2 weeks review > period, please try to review twice as many other submissions that have > been patiently waiting on the patches tracker :-)", or some stats > crunched and advertised periodically to guix-devel or even our to our > blog about our top reviewers, etc.). In release announcements, alongside to the the normal `git shortlog` list of authors, I suggest also publicizing the list of committers: `git shortlog --numbered --summary --committer v1.4.0..HEAD` A small thing, but hopefully one of many incentives to review and commit.
On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote: > Hi Simon, > > Simon Tournier <zimon.toutoune@gmail.com> writes: > > > Hi, > > > > On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote: > > > >> 1) Every current and potential new package is covered by a team. > >> 2) Every team has at least 3 members, better yet 4 or 5. > >> 3 members would make it possible that even if one of them is on vacation > >> or otherwise busy a patch could be pushed without this additional one > >> week if the other 2 agree. > > > > It would help if being committer implies appearing at least in one team, > > no? > > > > Currently in etc/teams.scm.in, I count 26 members and 20 are committers > > over the 48 ones. No blame. :-) > > If most committers end up being team members, aren't we back to where we > currently stand? It seems the original motivation here is to add some > extra control/guards against undesirable commits landing in the core of > Guix. If a committer that previously landed such commits joined the > core team (e.g., myself), it seems to me the situation would be little > changed: My understanding was that it would help people feel more ownership over a portion of the code, allowing others to tag them explicitly for code review touching their area of expertise and allowing them to perhaps "pay less attention" to areas where they are less sure. The second part works better when all areas are covered by a team, but in practice I feel it was already happening, judging by our large backlog of patches. > 1. Our pool of reviewers would likely continue to be spread too thin. > > 2. The 2 weeks time window would quickly slip, even with a team looking > at a more focused backlog, or the reviews would only be of the kind "I > think that's not what we want" without more time or energy to offer the > kind of concrete insights that can be turned into action for the > submitter. > > 3. The team member might be tempted to take their chance and merge their > change with little to no feedback, or feedback they perceived > insufficient or not actionable enough to justify keeping their > submission in limbo for longer. > > I think the main problem we have is social, not organizational. There's > little incentive to jump into the laborious review process compared to > hack on something we like in our free time. We need to promote and > value review work more, without making it feel like a compulsory chore. > That's a great challenge to solve for a project that's driven by > volunteers. > > I'll venture a suggestion to explore: adding enticements to review (some > playful guidelines such as "while waiting for your 2 weeks review > period, please try to review twice as many other submissions that have > been patiently waiting on the patches tracker :-)", or some stats > crunched and advertised periodically to guix-devel or even our to our > blog about our top reviewers, etc.). > > -- > Maxim
Hi Efraim, Efraim Flashner <efraim@flashner.co.il> writes: > On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote: >> Hi Simon, >> >> Simon Tournier <zimon.toutoune@gmail.com> writes: >> >> > Hi, >> > >> > On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote: >> > >> >> 1) Every current and potential new package is covered by a team. >> >> 2) Every team has at least 3 members, better yet 4 or 5. >> >> 3 members would make it possible that even if one of them is on vacation >> >> or otherwise busy a patch could be pushed without this additional one >> >> week if the other 2 agree. >> > >> > It would help if being committer implies appearing at least in one team, >> > no? >> > >> > Currently in etc/teams.scm.in, I count 26 members and 20 are committers >> > over the 48 ones. No blame. :-) >> >> If most committers end up being team members, aren't we back to where we >> currently stand? It seems the original motivation here is to add some >> extra control/guards against undesirable commits landing in the core of >> Guix. If a committer that previously landed such commits joined the >> core team (e.g., myself), it seems to me the situation would be little >> changed: > > My understanding was that it would help people feel more ownership over > a portion of the code, allowing others to tag them explicitly for code > review touching their area of expertise and allowing them to perhaps > "pay less attention" to areas where they are less sure. The second part > works better when all areas are covered by a team, but in practice I > feel it was already happening, judging by our large backlog of patches. I believe that's the original rationale behind teams. But the change being discussed here proposes to add a policy to make teams the governing body of changes that touch their area (gating the patches applied), which is something else. That alone sounds like a good idea, assuming teams are healthy and functional. But the aim of the proposed change is to reducing friction between committers, or "pacifying" collaboration, to quote the original message. I don't think such policy will help *much* in that regard, since most of the teams people are the same people as the committers. It'll help some in the sense the group interacting together on merging patches will be smaller, but at the cost of reduced throughput, I reckon. On a side note, it would also introduce some kind of hierarchy in the group, which I dislike. One of the things that make Guix special is that it's pretty flat -- everybody can participate at the same level, at least between committers). I'd rather we don't try to emulate Debian on that point.
Hi Leo, Leo Famulari <leo@famulari.name> writes: [...] > In release announcements, alongside to the the normal `git shortlog` > list of authors, I suggest also publicizing the list of committers: > > `git shortlog --numbered --summary --committer v1.4.0..HEAD` > > A small thing, but hopefully one of many incentives to review and > commit. Seems an easy thing to do; but in the context of this discussion we'd like to emphasizes the reviewers rather than just the committers (otherwise Ricardo would always appear at the top, thanks to the sheer number of their R package updates (thanks!)). It seems starting to use the 'Reviewed-by' git message tag would make this easy to account for.
On 2023-03-08, Maxim Cournoyer wrote: > On a side note, it would also introduce some kind of hierarchy in the > group, which I dislike. One of the things that make Guix special is > that it's pretty flat -- everybody can participate at the same level, at > least between committers). I'd rather we don't try to emulate Debian on > that point. I have been watching this thread with great curiosity for exactly this reason! One of the things I like about Guix, coming from a couple decades of involvement with Debian, is the lack of package "ownership" ... in Debian, any Debian Developer with upload rights can technically upload any package, but it is considered inappropriate to do so without following various processes. Over the years, ways to opt-in to streamlined processes now exist, but the norm is still very much package "ownership". Guix is starting from a much more flexible model, but struggling with challenges of scale ... a small number of people maintaining a huge number of packages. I am a bit concerned that formalizing this much process for teams just yet... There is not much granularity of team scope and responsibilities. The current teams implementation seems to involve claiming one or more gnu/packages/*.scm files (or other files)... but not individual packages or groups of packages within one of those. It seems quite rough around the edges and I am concerned about how it will play out to further formalize the process. I almost wonder if it wouldn't be good to spell out what exactly is desired to be accomplished by having teams? Maybe much of that conversation has already happened, but ... spelling it out first, and then trying to come up with implementation details that attempt to fit the goals? I have a hunch that this dish might benefit from a bit more seasoning. I am not sure exactly which herbs and spices to reach for, or how long to leave it simmering on the stove... but I know people are getting hungry! live well, vagrant
Hi, Vagrant Cascadian <vagrant@debian.org> writes: [...] > I almost wonder if it wouldn't be good to spell out what exactly is > desired to be accomplished by having teams? Maybe much of that > conversation has already happened, but ... spelling it out first, and > then trying to come up with implementation details that attempt to fit > the goals? I believe the original goal of teams was to offer a more focus stream of patches to review for those adhering to a specific team. I'll let the implementers of teams.scm correct me if I got that wrong :-).
Hi, On Wed, 08 Mar 2023 at 13:58, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > number of their R package updates (thanks!)). It seems starting to use > the 'Reviewed-by' git message tag would make this easy to account for. Quoting from thread [1]: I agree that Reviewed-by would be helpful. Once reviewed, the author or the reviewer could roll the count and re-send the patch (or series), applying the line Reviewed-by. It would reward the reviewer for their work. And it would help the committer work. Subject: Thoughts on committers pushing simple changes from other committers? 1: <https://yhetil.org/guix/86k00avhpv.fsf@gmail.com> Cheers, simon
Hi Maxim, On Wed, 08 Mar 2023 at 12:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > On a side note, it would also introduce some kind of hierarchy in the > group, which I dislike. One of the things that make Guix special is > that it's pretty flat -- everybody can participate at the same level, at > least between committers). I'd rather we don't try to emulate Debian on > that point. Hierarchy already exists, as in any social group, as in any group of people collaborating. The hierarchy is currently informal. And it is not really “pretty flat” because some individuals from that group have more (informal) power than other. That’s not necessary a bad thing. :-) For instance, the access to the build farms is restricted, the ability to restart Cuirass job is restricted, commit access is restricted, money spending is restricted, etc. What I see as a bad thing is the informal part. Far from me the willing of being confrontational, I just would like to point that you are somehow on the top of the “hierarchy” so you see it as “pretty flat”, when it is not. And if you want to experiment, try to spend one month using only guix-devel and guix-patches for collaborating and you will see. :-) That’s said, Guix is awesome! I came because technical features and I am still here because the community is welcoming, friendly, helping and I really enjoy the way we are collaborating altogether. I totally agree that everyone can participate and we, as a group, are trying hard to be welcoming and friendly, so that everybody can participate and/or acquire more knowledge and/or skill, and from my point of view, we try hard to take into account all the voices. By daily interactions, we are doing our best in this area – even often rehashing how we can improve. And for what it is worth, I will do all my best so that this will not change. :-) Now, we, as a community of volunteers, have one problem, well, two related problems: (1) not enough people are reviewing (2) there is no “duty” or “accountability” These is becoming more apparent because Guix is growing and that’s a good thing. And we have to adapt our practices for a better scaling, IMHO. This “teams” is somehow a proposal as an attempt to address (1) and (2). Please, do not take me wrong with the quoted duty and accountability. Motivation by volunteers is non-fungible, for sure. That’s does not mean that a subgroup cannot commit for some tasks. That’s already the case, guix-maintainers is committed to “duties” as explained by [1]. For instance, it reads « the other responsibilities can be delegated: - Making releases. - Dealing with development and its everyday issues as well as … - Participating in [internship progam] - Organizing [events] - Taking care of Guix money … - Keeping the build farm infrastructure up - Keeping the web site up-to-date. - Looking after people » Therefore, could you please point me who or how these responsibilities are delegated? From my point of view, “teams” is an attempt to accomplish that delegation. Me too, I am not convinced that the heavy “bureaucracy“ of Debian is something that I would like with Guix. However, there is gap between the addition of more explicit structure in Guix as “teams” is a proposal and keep the current informal structure. Cheers, simon 1: https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/
Hi Simon et al., Simon Tournier <zimon.toutoune@gmail.com> writes: > Hi Maxim, > > On Wed, 08 Mar 2023 at 12:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > >> On a side note, it would also introduce some kind of hierarchy in the >> group, which I dislike. One of the things that make Guix special is >> that it's pretty flat -- everybody can participate at the same level, at >> least between committers). I'd rather we don't try to emulate Debian on >> that point. > > Hierarchy already exists, as in any social group, as in any group of > people collaborating. The hierarchy is currently informal. > > And it is not really “pretty flat” because some individuals from that > group have more (informal) power than other. That’s not necessary a bad > thing. :-) For instance, the access to the build farms is restricted, > the ability to restart Cuirass job is restricted, commit access is > restricted, money spending is restricted, etc. Apologies for starting a tangent (which is interesting in its own!). Rewinding to the beginning, I believe the novelty proposed in this patch is (quoting the original message): > With the proposed policy, members of a team would also have to review > and approve each other’s work. Formal approval means getting an > explicit “LGTM” (or similar) from at least one other team member. In other words, to give teams the power to gate the changes touching their scope. That's reasonable, if we have functional teams. I'd argue we aren't there yet. And also: > I think it avoids the unavoidable misunderstandings that can arise in > a growing group and help pacify day-to-day collaboration. Again, "pacify" irks me a bit in this sentence, given I consider collaboration has and continues to be cordial in our community, unless I've been living under a rock.
Hello Simon, Am Thu, Mar 09, 2023 at 10:46:08AM +0100 schrieb Simon Tournier: > Hierarchy already exists, as in any social group, as in any group of > people collaborating. The hierarchy is currently informal. while I am sensitive to your argument about privileges, I am afraid that the suggestion would remove privileges from the committers, while not bestowing them on anybody else; as a result, everybody would be worse off than before. Right now one out of the (let us be pessimistic) 20 active committers can push any patch from the issue tracker, say for a package trivially obtained via "guix import pypi ...". With the suggested change, the currently 1 (and in future hopefully one out of a few) members of the python group will have to approve the patch. In that situation, there is no incentive for anybody else to even look at the patch (without agency, why would one bother?), and we will effectively have split the Guix project into a collection of walled gardens. I think this suggestion has the potential to make a stuttering project grind to a complete halt. And I am afraid that we are on a track to replacing joy, agency and community by grind and bureaucracy. I suggest to close this issue due to a weak consensus against the proposal (or at least the lack of a clear consensus for it). Andreas
Hello Maxim and all! Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: >> With the proposed policy, members of a team would also have to review >> and approve each other’s work. Formal approval means getting an >> explicit “LGTM” (or similar) from at least one other team member. > > In other words, to give teams the power to gate the changes touching > their scope. That's reasonable, if we have functional teams. I'd argue > we aren't there yet. I kinda agree; bootstrapping issue then? I hope the maintainer team can help make teams “more functional”, whatever that teams. It’s really what maintainership is about in Guix; it’s not about writing code. > And also: >> I think it avoids the unavoidable misunderstandings that can arise in >> a growing group and help pacify day-to-day collaboration. > > Again, "pacify" irks me a bit in this sentence, given I consider > collaboration has and continues to be cordial in our community, unless > I've been living under a rock. “Pacify” in the sense that, by being explicit, we avoid misunderstandings that could turn into unpleasant experiences. Like you I’m glad collaboration is nice and friendly; yet, over the past few months I’ve experienced misunderstandings that seemingly broke the consensus-based process that has always prevailed. In a way, that’s probably bound to happen as the group grows, and I think that’s why we must be explicit about what the process is and about whether one is expressing consent or dissent. With so many things happening in Guix (yay!), it’s also easy to overlook a change and realize when it’s too late. By having a rule that at least one other person on the team must approve (consent to) a change, we reduce that risk. Being on a team, then, is a way to express interest on a topic and to be “in the loop”. It is not about asserting power or building a hierarchy; it’s about formalizing existing relations and processes. I hope this clarifies my position! Ludo’.
Hi Andreas, Re-reading the thread, I think we started with different frames. :-) On ven., 10 mars 2023 at 15:19, Andreas Enge <andreas@enge.fr> wrote: > while I am sensitive to your argument about privileges, I am afraid that > the suggestion would remove privileges from the committers, while not > bestowing them on anybody else; as a result, everybody would be worse off > than before. Right now one out of the (let us be pessimistic) 20 active > committers can push any patch from the issue tracker, say for a package > trivially obtained via "guix import pypi ...". With the suggested change, > the currently 1 (and in future hopefully one out of a few) members of the > python group will have to approve the patch. In that situation, there is > no incentive for anybody else to even look at the patch (without agency, > why would one bother?), and we will effectively have split the Guix project > into a collection of walled gardens. What you are pointing is that not all the teams are willing to collaborate the same way. For sure I agree that updating a leaf package does not require any more extra work – processing the submission by the committer is already enough boring work. However, for some packages or changes, the impact is far from being trivial. I have in mind many changes that happen aside gnu/packages and also some core packages (Guile, etc.). For these kind of changes, it does not appear to me so crazy to ask more than the submitter or committer eyes. For instance, one can read from recent messages, this "trivial" patch implies a Julia (almost) world rebuild -- so potentially some breakages. And personally, I cannot run again and again after broken packages from unrelated changes. :-) or To be clear, it’s time-consuming and stressful. That’s not sane and I’d rather not work that way. https://yhetil.org/guix/CAJ3okZ3j+HTATsoGE978b+LGk0KAEM7-BAGSy_Gtm61FzTWwQA@mail.gmail.com https://yhetil.org/guix/87cz5qyv10.fsf@gnu.org The wording of the patch is misleading but, I guess, the intent is to smooth these kind of situations. For sure, QA is helping a lot but there is still limitations. Consider this thread [1] about updating Git. We do not have the capacity to let QA check that all is fine. Again considering [1], it appears to me reasonable to ask that more than two people (Greg and I) give a look, thus this thread [1] appears to me sane. For some changes aside packages, QA is helpless. Yeah we can improve the Guix test suite and increase the coverage. But still, for some changes, the collateral effect is often hard to evaluate. Hence, ask for another look to be considered as green light appears to me fine. I guess that the intent of this patch #61894 and I agree that the wording is probably poor for that intent. :-) Well, instead of closing, I think this patch requires an update. Since Guix is growing and that’s a good thing, it implies two things: (a) that more people are relying on it so for some part we need less unexpected breakage and (b) that some implicit that worked until now needs to be more explicit. Yeah, the corollary of (a) is moving less fast for some part. But there is no free lunch. ;-) And (b) does not mean strong all white or all black. Cheers, simon 1: <https://yhetil.org/guix/20230217180402.29401-1-code@greghogan.com/#r>
Hi Ludo', On Fri, Mar 10, 2023 at 9:22 AM Ludovic Courtès <ludo@gnu.org> wrote: > > Like you I’m glad collaboration is nice and friendly; yet, over the past > few months I’ve experienced misunderstandings that seemingly broke the > consensus-based process that has always prevailed. I have no idea what happened there, but it may be best to be open and direct about it. Would it be helpful for everyone to share details? Although you know that already, it would be best to avoid accusations and look inward with statements like "I was unhappy about ... because of ...." I might also avoid the word "you" and instead address all messages to a third party. When unhappy, we could write to "Yogi Bear". Alternatives would be "Scooby-Doo" or "Winnie the Poo". They do something similar in the parliaments around the world. I picked unisex characters for that reason (although all three appear a bit more male than female). Also, why not retitle the bug as "Restore and improve our consensus-based process"? Thanks to everyone for working on Guix! We have a truly great, warm and welcoming community. Kind regards Felix
Am Fri, Mar 10, 2023 at 06:33:58PM +0100 schrieb Simon Tournier: > However, for some packages or changes, the impact is far from being > trivial. I have in mind many changes that happen aside gnu/packages and > also some core packages (Guile, etc.). > For these kind of changes, it does not appear to me so crazy to ask more > than the submitter or committer eyes. That is true! So far, this has been handled by common sense of the people working on a patch (and sometimes that process then fails). > (b) that some implicit that worked until now needs to be more explicit. > And (b) does not mean strong all white or all black. In the longer run I also agree with (b). But I am not sure it will be easy to formulate a rule that captures well the intended policy and draws the line between "trivial", anybody can push any time, and "complex", where more opinions are needed, and maybe stages in between. It may be worth the trial. Andreas
Hi, On Sat, 11 Mar 2023 at 00:19, Andreas Enge <andreas@enge.fr> wrote: > In the longer run I also agree with (b). But I am not sure it will be easy > to formulate a rule that captures well the intended policy and draws the > line between "trivial", anybody can push any time, and "complex", where more > opinions are needed, and maybe stages in between. It may be worth the trial. I agree. How to find the right balance between no guard and too many stones if not rocks crossing the path? Cheers, simon
Hi Felix, Felix Lechner <felix.lechner@lease-up.com> writes: > Hi Ludo', > > On Fri, Mar 10, 2023 at 9:22 AM Ludovic Courtès <ludo@gnu.org> wrote: >> >> Like you I’m glad collaboration is nice and friendly; yet, over the past >> few months I’ve experienced misunderstandings that seemingly broke the >> consensus-based process that has always prevailed. > > I have no idea what happened there, but it may be best to be open and > direct about it. Would it be helpful for everyone to share details? It may help to shed a bit of light on the original reason I think this change came into existence, and in the interest of transparency and hopefully improving or finding alternatives to the proposed change, I consent to Ludovic openly discussing it, even if it involves a healthy dose of critique and looking inward. > Although you know that already, it would be best to avoid accusations > and look inward with statements like "I was unhappy about ... because > of ...." I might also avoid the word "you" and instead address all > messages to a third party. [...] > Also, why not retitle the bug as "Restore and improve our > consensus-based process"? I think this captures well what one of the issues I see with this change: it seems to be an attempt to resolve a local conflict (?) by apply a new global policy (which could be OK if the problem was widespread, but I doubt it is?), making everyone pay for it (via added bureaucracy). I've also pointed that if this is what it's trying to fix, it won't really help, since policy is not a substitute to consensus, and we're the same pool of people who will need to get along, whether as committers or as members of the same team.
Hi Ludovic, Ludovic Courtès <ludo@gnu.org> writes: > Hello Maxim and all! > > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > >>> With the proposed policy, members of a team would also have to review >>> and approve each other’s work. Formal approval means getting an >>> explicit “LGTM” (or similar) from at least one other team member. >> >> In other words, to give teams the power to gate the changes touching >> their scope. That's reasonable, if we have functional teams. I'd argue >> we aren't there yet. > > I kinda agree; bootstrapping issue then? Bootstrapping, yes, but also tooling, and people not yet catching up. As I've pointed before, we've had the doc mentioning a command which doesn't work to notify teams since at least October of last year [0] and it seems few people even noticed (I think you only did recently :-)), which tells me it's not a very well-trodden path yet! [0] https://issues.guix.gnu.org/58813 > I hope the maintainer team can help make teams “more functional”, > whatever that teams. It’s really what maintainership is about in Guix; > it’s not about writing code. I'm happy to help with the effort, but I don't think it's particularly relevant to Guix co-maintainers more than anyone else interested in advancing/contributing to Guix, and I find it great that it's this way (not out of laziness, but because the talent pool of the whole Guix community is much larger that that of us 4 co-maintainers). Per what we co-maintainers signed up for in [1], the co-maintainers three primary duties are: Enforcing GNU and Guix policies, such as the project’s commitment to be released under a copyleft free software license (GPLv3+) and to follow the Free System Distribution Guideline (FSDG). Enforcing our code of conduct: maintainers are the contact point for anyone who wants to report abuse. Making decisions, about code or anything, when consensus cannot be reached. We’ve probably never encountered such a situation before, though! [1] https://guix.gnu.org/en/blog/2019/gnu-guix-maintainer-collective-expands/ >> And also: >>> I think it avoids the unavoidable misunderstandings that can arise in >>> a growing group and help pacify day-to-day collaboration. >> >> Again, "pacify" irks me a bit in this sentence, given I consider >> collaboration has and continues to be cordial in our community, unless >> I've been living under a rock. > > “Pacify” in the sense that, by being explicit, we avoid > misunderstandings that could turn into unpleasant experiences. > > Like you I’m glad collaboration is nice and friendly; yet, over the past > few months I’ve experienced misunderstandings that seemingly broke the > consensus-based process that has always prevailed. I'm sorry that you feel that way. I don't think consensus was willfully broken, and perhaps by studying some actual examples of these occurrences we can better understand what went wrong and how the new suggested policy would have helped or could be modified to help avoid such problems in the future. It's also worth noting that this consensus-based process has always been implicit; for example, it is not defined/mentioned anywhere in our documentation. Perhaps it should? > In a way, that’s probably bound to happen as the group grows, and I > think that’s why we must be explicit about what the process is and about > whether one is expressing consent or dissent. > > With so many things happening in Guix (yay!), it’s also easy to overlook > a change and realize when it’s too late. By having a rule that at least > one other person on the team must approve (consent to) a change, we > reduce that risk. > > Being on a team, then, is a way to express interest on a topic and to be > “in the loop”. That's already what teams can do! I'd argue giving them the extra powers that would be conferred to teams in this is not needed/desirable. Some committer not a regular member of X team may still be confident enough to push a patch sitting on the tracker, and I think they should be able to. > It is not about asserting power or building a hierarchy; > it’s about formalizing existing relations and processes. OK; I think in practice it would amount to that though (building a hierarchy which has some form power). > I hope this clarifies my position! Yes, it does. Thanks for taking the time to field some of the questions!
Hi, On Sat, 11 Mar 2023 at 21:33, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > It may help to shed a bit of light on the original reason I think this > change came into existence, and in the interest of transparency and > hopefully improving or finding alternatives to the proposed change, I > consent to Ludovic openly discussing it, even if it involves a healthy > dose of critique and looking inward. There is no one original reason but several diffuse situations. Well, I have tried to provide the context and the intent behind the patch in this message here: https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00121.html Although I agree that the wording of the initial Ludo’s proposal is not the one I would like, it does not appear to me so crazy to ask another LGTM for some part of the code. Double-check leaf Python package is not worth and it adds a lot of unnecessary burden. We all agree here, I guess. Double-check core packages or Guile build-side code sounds to me totally reasonable. The initial wording of the proposal, --8<---------------cut here---------------start------------->8--- +When your patch falls under the area of expertise of a team +(@pxref{Teams}), you need the explicit approval of at least one team +member before committing (another team member if you are on the team). --8<---------------cut here---------------end--------------->8--- cannot apply for all the teams. Again, we all agree I guess. However, this proposal appears to me totally sane for what is under the scope of the team named ’core’ for instance. Instead of a strong opposition, the patch needs an update. Cheers, simon
Hello, Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer: > Ludovic Courtès <ludo@gnu.org> writes: > > I hope the maintainer team can help make teams “more functional”, > > whatever that teams. It’s really what maintainership is about in Guix; > > it’s not about writing code. > I'm happy to help with the effort, but I don't think it's particularly > relevant to Guix co-maintainers more than anyone else interested in > advancing/contributing to Guix, and I find it great that it's this way > (not out of laziness, but because the talent pool of the whole Guix > community is much larger that that of us 4 co-maintainers). Per what we > co-maintainers signed up for in [1], the co-maintainers three primary > duties are: but there is also "Looking after people: making sure to promote people who are very involved in leadership position; dubbing new committers, new maintainers, new members of the spending committee. Supporting new initiatives. Generally trying to make sure everyone’s happy. :-)" As for all "management positions" (even if we may not like the term here as it often evokes a hierarchy; maybe "board members of a non-profit" captures the idea better), I think the maintainers' role is more about moderating ("animer" in French, which I think is more to the point), keeping the overview, overseeing and facilitating initiatives, making sure the project moves on, etc., than day to day work on details, or the three technical points you mention (and which probably hardly ever require action). Maybe it would be time to move on to something like the Debian Social Contract and concrete rules how membership, commit rights, maintainer roles in the Guix project are bestowed and what is expected from people fulfilling such roles. Andreas
Hi Maxim, On Sat, 11 Mar 2023 at 22:26, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > I'm sorry that you feel that way. I don't think consensus was willfully > broken, and perhaps by studying some actual examples of these > occurrences we can better understand what went wrong and how the new > suggested policy would have helped or could be modified to help avoid > such problems in the future. Well, all is in the public archive. :-) For one recent example, see #61255 [1]: --8<---------------cut here---------------start------------->8--- We should think about how to improve our processes to avoid such issues in the future. I did raise concerns about this very patch late at night during FOSDEM, 24h after submission, and reaffirmed my viewpoint days later. I understand that delaying a nice patch series like this one is unpleasant, but I think those concerns should have been taken into account. --8<---------------cut here---------------end--------------->8--- 1: https://issues.guix.gnu.org/issue/61255#32 From my point of view, it is useless to rehash specific example by specific example. Because it is not one unique case but several diffuse situations popping here or there. To be honest, I am missing what are the objections when one is asking to double-check some core changes. Anyway, I have expressed my opinion in various places in this thread and now I will not comment further. Cheers, simon
Hi Andreas, Andreas Enge <andreas@enge.fr> writes: > Hello, > > Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer: >> Ludovic Courtès <ludo@gnu.org> writes: >> > I hope the maintainer team can help make teams “more functional”, >> > whatever that teams. It’s really what maintainership is about in Guix; >> > it’s not about writing code. >> I'm happy to help with the effort, but I don't think it's particularly >> relevant to Guix co-maintainers more than anyone else interested in >> advancing/contributing to Guix, and I find it great that it's this way >> (not out of laziness, but because the talent pool of the whole Guix >> community is much larger that that of us 4 co-maintainers). Per what we >> co-maintainers signed up for in [1], the co-maintainers three primary >> duties are: > > but there is also > "Looking after people: making sure to promote people who are very involved > in leadership position; dubbing new committers, new maintainers, new > members of the spending committee. Supporting new initiatives. Generally > trying to make sure everyone’s happy. :-)" Yes, I've only quoted the core duties of the maintainers, because we struggle to do much of anything else; thankfully, many individuals in the our community mostly fill in the gaps (thanks!). I'm aware that ideally we would do more: if you are interested in giving a hand, let guix-maintainers know -- we're currently 4 and could do with a 5th person onboard to smooth out operations). > As for all "management positions" (even if we may not like the term here > as it often evokes a hierarchy; maybe "board members of a non-profit" > captures the idea better), I think the maintainers' role is more about > moderating ("animer" in French, which I think is more to the point), > keeping the overview, overseeing and facilitating initiatives, making sure > the project moves on, etc., than day to day work on details, or the three > technical points you mention (and which probably hardly ever require > action). Past maintainers will probably smile at the "hardly ever require actions" :-). But you are right, the occurrences of things like CoC complaints or other requests sent over email are not constant in time (but it doesn't mean they are easy or quick to resolve). That said, I agree with the general idea about maintainers having a role to play in smoothing out interactions (which I believe we are doing) and shepherding efforts toward a common goal (which I don't think we are doing much at all). > Maybe it would be time to move on to something like the Debian Social > Contract and concrete rules how membership, commit rights, maintainer > roles in the Guix project are bestowed and what is expected from > people fulfilling such roles. I'm not sure how something like the Debian Social Contract would help here, and I do not know that "membership" has a meaning in our community. As I mentioned before, I feel like our problems are mostly social rather than organizational (such as the question about how to motivate people to review more), so I'd rather focusing on that more than adding organizational layers. I'll now leave the discussion space to other participants, as I feel like I've already used too much of it :-).
Hello! Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: [...] >> “Pacify” in the sense that, by being explicit, we avoid >> misunderstandings that could turn into unpleasant experiences. >> >> Like you I’m glad collaboration is nice and friendly; yet, over the past >> few months I’ve experienced misunderstandings that seemingly broke the >> consensus-based process that has always prevailed. > > I'm sorry that you feel that way. I don't think consensus was willfully > broken, That’s my point: by being explicit about approval, we would avoid such misunderstandings. > and perhaps by studying some actual examples of these occurrences we > can better understand what went wrong and how the new suggested policy > would have helped or could be modified to help avoid such problems in > the future. I don’t want to rehash past occurrences of this problem. It boils down to: changes where pushed despite consensus evidently not being met, at least not in the mind of every involved party. To some extent, that’s bound to happen due to an increase of the number of contributors, scope of the project, and diversity of backgrounds. By making it clear that lack of “LGTM” from another team member equates with lack of consensus, we would avoid those misunderstandings. A good reference on consensus-based decision making is <https://www.seedsforchange.org.uk/consensus>. > It's also worth noting that this consensus-based process has always > been implicit; for example, it is not defined/mentioned anywhere in > our documentation. Perhaps it should? Those who’ve followed the project long enough, such as part of the current maintainer collective, are certainly aware of that; it’s also spelled out in <https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/>. That said, again in the spirit of improving legibility, writing it down would be much welcome. >> In a way, that’s probably bound to happen as the group grows, and I >> think that’s why we must be explicit about what the process is and about >> whether one is expressing consent or dissent. >> >> With so many things happening in Guix (yay!), it’s also easy to overlook >> a change and realize when it’s too late. By having a rule that at least >> one other person on the team must approve (consent to) a change, we >> reduce that risk. >> >> Being on a team, then, is a way to express interest on a topic and to be >> “in the loop”. > > That's already what teams can do! Yes and no. With the amount of activity going on, it’s easy to overlook something. The explicit synchronization point could mitigate that. > I'd argue giving them the extra powers that would be conferred to > teams in this is not needed/desirable. Some committer not a regular > member of X team may still be confident enough to push a patch sitting > on the tracker, and I think they should be able to. Self-assessment becomes tricky that this scale; I might be confident and yet someone will point out a problem (that literally happened to me two days ago in <https://issues.guix.gnu.org/62062>). That’s when review really helps. For “core” work, I insist that explicit approval (and thus peer review) is necessary. I doubt anyone would seriously challenge that. Now, I agree, as I wrote before, that this may be overkill for “random packages”. Thus we need to find the right balance. What about team/scope-specific rules? As in: “Changes covered by teams X, Y, and Z need to be explicitly approved by at least one other member of the team.” >> It is not about asserting power or building a hierarchy; >> it’s about formalizing existing relations and processes. > > OK; I think in practice it would amount to that though (building a > hierarchy which has some form power). I disagree: just because power relations are not spelled out doesn’t mean they don’t exist. I don’t know where you’re talking from; one thing that to me shed light on these matters is “The Tyranny of Structurelessness” (I’m sure I mentioned it before, I certainly did during Q&A on this very topic at the Ten Years event; apologies if I sound like a broken record!). Thanks, Ludo’.
Hi Ludovic, Ludovic Courtès <ludo@gnu.org> writes: > Hello! > > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > > [...] > >>> “Pacify” in the sense that, by being explicit, we avoid >>> misunderstandings that could turn into unpleasant experiences. >>> >>> Like you I’m glad collaboration is nice and friendly; yet, over the past >>> few months I’ve experienced misunderstandings that seemingly broke the >>> consensus-based process that has always prevailed. >> >> I'm sorry that you feel that way. I don't think consensus was willfully >> broken, > > That’s my point: by being explicit about approval, we would avoid such > misunderstandings. > >> and perhaps by studying some actual examples of these occurrences we >> can better understand what went wrong and how the new suggested policy >> would have helped or could be modified to help avoid such problems in >> the future. > > I don’t want to rehash past occurrences of this problem. It boils down > to: changes where pushed despite consensus evidently not being met, at > least not in the mind of every involved party. > > To some extent, that’s bound to happen due to an increase of the number > of contributors, scope of the project, and diversity of backgrounds. By > making it clear that lack of “LGTM” from another team member equates > with lack of consensus, we would avoid those misunderstandings. I agree that firm conventions here would make things smoother. It's common that someone offers an incomplete review or just forget the LGTM, and the author is left to ask if it's OK to push or not or assume it is. > A good reference on consensus-based decision making is > <https://www.seedsforchange.org.uk/consensus>. > >> It's also worth noting that this consensus-based process has always >> been implicit; for example, it is not defined/mentioned anywhere in >> our documentation. Perhaps it should? > > Those who’ve followed the project long enough, such as part of the > current maintainer collective, are certainly aware of that; it’s also > spelled out in > <https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/>. > > That said, again in the spirit of improving legibility, writing it down > would be much welcome. Yes, I've heard 'consensus' for years, and I think I have a good enough understanding of it, but I think there are subtleties many (including myself) fail to appreciate that the above link explains well, so I think there's value in mentioning it somewhere. I'll send a patch for everyone to review. >>> In a way, that’s probably bound to happen as the group grows, and I >>> think that’s why we must be explicit about what the process is and about >>> whether one is expressing consent or dissent. >>> >>> With so many things happening in Guix (yay!), it’s also easy to overlook >>> a change and realize when it’s too late. By having a rule that at least >>> one other person on the team must approve (consent to) a change, we >>> reduce that risk. >>> >>> Being on a team, then, is a way to express interest on a topic and to be >>> “in the loop”. >> >> That's already what teams can do! > > Yes and no. With the amount of activity going on, it’s easy to overlook > something. The explicit synchronization point could mitigate that. > >> I'd argue giving them the extra powers that would be conferred to >> teams in this is not needed/desirable. Some committer not a regular >> member of X team may still be confident enough to push a patch sitting >> on the tracker, and I think they should be able to. > > Self-assessment becomes tricky that this scale; I might be confident and > yet someone will point out a problem (that literally happened to me two > days ago in <https://issues.guix.gnu.org/62062>). That’s when review > really helps. > > For “core” work, I insist that explicit approval (and thus peer review) > is necessary. I doubt anyone would seriously challenge that. > > Now, I agree, as I wrote before, that this may be overkill for “random > packages”. > > Thus we need to find the right balance. > > What about team/scope-specific rules? As in: “Changes covered by teams > X, Y, and Z need to be explicitly approved by at least one other member > of the team.” To me, it seems challenging to partition the code correctly and avoid overloading the core team with spurious changes, which would slow things down more (as the core team would be a fraction of the committers currently enabled to push such changes), but I agree in principle that it makes sense. >>> It is not about asserting power or building a hierarchy; >>> it’s about formalizing existing relations and processes. >> >> OK; I think in practice it would amount to that though (building a >> hierarchy which has some form power). > > I disagree: just because power relations are not spelled out doesn’t > mean they don’t exist. I don’t know where you’re talking from; one > thing that to me shed light on these matters is “The Tyranny of > Structurelessness” (I’m sure I mentioned it before, I certainly did > during Q&A on this very topic at the Ten Years event; apologies if I > sound like a broken record!). As with anything there's probably a middle ground to reach, where there's some structure, but not too much, that maximizes our collective happiness.
Hello, Ludovic Courtès <ludo@gnu.org> skribis: > With the proposed policy, members of a team would also have to review > and approve each other’s work. Formal approval means getting an > explicit “LGTM” (or similar) from at least one other team member. I think it’s fair to say that there was no consensus on this proposal, so I’m withdrawing it and closing this issue. Thanks to everyone who contributed to the discussion! Ludo’.
diff --git a/doc/contributing.texi b/doc/contributing.texi index c436bc4a31..d8ca6802c4 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -1486,7 +1486,7 @@ reply to incoming bugs and patches, which contains the bug number. @anchor{Notifying Teams} @cindex teams The @file{etc/teams.scm} script may be used to notify all those who -may be interested in your patch of its existence (@pxref{Teams}). +may be interested in your patch and may approve it (@pxref{Teams}). Use @command{etc/teams.scm list-teams} to display all the teams, decide which team(s) your patch relates to, and use @command{etc/teams.scm cc} to output various @command{git send-email} @@ -1557,6 +1557,9 @@ these changes are necessary. @subsection Teams @cindex teams +The project is structured as @dfn{teams}, which play two related roles: +mentoring people who contribute code in their area of expertise, and +reviewing and approving changes to that code. There are several teams mentoring different parts of the Guix source code. To list all those teams, you can run from a Guix checkout: @@ -1840,8 +1843,14 @@ Patches}). It also allows patches to be picked up and tested by the quality assurance tooling; the result of that testing eventually shows up on the dashboard at @indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where -@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave -time for a review, without committing anything (@pxref{Submitting +@var{ISSUE_NUMBER} is the number assigned by the issue tracker. + +When your patch falls under the area of expertise of a team +(@pxref{Teams}), you need the explicit approval of at least one team +member before committing (another team member if you are on the team). + +In other cases, +leave time for a review, without committing anything (@pxref{Submitting Patches}). If you didn’t receive any reply after one week (two weeks for more significant changes), and if you're confident, it's OK to commit.