[GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek]

Hi there,

st 13. 3. 2024 v 1:36 odesílatel Vaclav Petras <wenzeslaus at gmail.com> napsal:
> On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek <pesej.ondrek at 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.rouault at 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