Hi there, st 13. 3. 2024 v 1:36 odesílatel Vaclav Petras <wenzesl...@gmail.com> napsal: > On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek <pesej.ond...@gmail.com> wrote: >> @Vaclav: Do you have some more points against the master-children >> schema? It seems that the general agreement is *for* the restructuring >> into parent and children teams. So far the only point against was "I >> didn't find team nesting particularly useful and we already had a >> couple of top-level teams." > > > ...and I didn't see it working for GDAL with people both in the parent team > and child teams and repos being assigned to both levels. > > How do you suggest we do it? Empty parent team without repos? Would that look > good?
According to [1], all the child teams inherit the rights of their parents. Therefore, I guess that having one empty parent with no rights is okay and the correct way (also, you can see all children members there, so it does not "look" empty even if it does not have any member). Then we could go one of the two ways: * Having all the current teams as child teams of the master team * Having it more structured (grass-addons, grass, grass-website/promo) I prefer the second way (some rights could then be propagated, I guess) but would appreciate even the first one as it would clean up the overview a lot. >> Although I appreciate all the work you >> dedicate to the GitHub management, I don't think that this is a valid >> point against when compared to the positive ones (although it's >> understandable that nobody wants to drop something that they have just >> created). > Thanks. It is more that before it was a high priority for me to get access > rights in order (access rights to individuals both directly and through > teams, inactive people from 2000s and early 2010s grandfathered into GitHub > write access, ...). These parent-child teams are low priority compared to > that. Okay, thanks for the explanation. I see the reasoning behind the drop of the priority and cannot disagree - nobody even seemed to notice that before. I agree that there are many more important things to do. Although I still think it would help the situation in the github teams. st 13. 3. 2024 v 1:57 odesílatel Even Rouault <even.roua...@spatialys.com> napsal: > FYI I see this thread referencing the GDAL github team organization. As far > as I know, nobody has "designed" it with deep thoughts. It has the current > structure most likely as an accident of history... If I were to design it, I > would keep it simple and stupid. With git workflows, the concept of > "committer" as in SVN era is kinda irrelevant. You just need a sufficient > number of people with appropriate push rights to merge the flow of incoming > PRs, but if you have more than 10 people with push rights in a single repo, > that is already quite big. My 2 cents, and running away as I've no idea how > the GRASS team works ;-) Thanks for the insight, Even. It seems that I am very much on the side of the accidental structure :-). [1] https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#nested-teams _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
