<div dir="ltr"><div dir="ltr">Huidae and Ondrej,</div><div dir="ltr"><br></div><div>I recently restructured the teams to reflect GitHub workflows and resulting needs for access (the original team structure was just used from Subversion access). Another reason was getting a better control over who can change the code directly (this is connected to the required PR reviews).<br></div><div dir="ltr"><br></div><div dir="ltr">We have 11 teams to cover our 4 repos and different levels of access (plus 2+1 legacy teams). Less would not allow us to give people specific properly-limited rights when needed, i.e., on a "need-to-have" basis. We have the minimum number of teams to drive write access on repo-to-repo basis to our 4 repos and make use of the 4 different relevant roles (4 Write teams, one for each repo, 1 Admin and 1 Maintain team for all repos, 1 Triage team, 1 special-purpose Triage team (discussion-moderators), 1 legacy Write (addons-subversion-committers), 1 legacy Triage (subversion-committers), 1 legacy Read (docker-homebrew-users)). More would be needed for specific task or organization reasons such as the current grass-discussion-moderators. Another reason to add more (possibly nested teams) would be when we would use it for reviews and/or notifications like "someone from the Windows team needs to review this PR", but it seems we are heading towards code owners rather than teams there (I don't pretend to know what are the differences or overlaps here).<br><br>If we say we want to cut down the number of teams, we can remove one or more of the following: 1 or 2 Subversion teams (legacy, but both are in use now), homebrew-docker team (complete legacy), grass-addons-write (could be merged with grass-write depending on how much it will be used, it has one person who is not in grass-write), grass-promo-write (can be merged with grass-website-write depending on in which way the grass-promo repo will be used).<br><br>For comparison, GDAL has 2 teams for 3 repositories plus a top-level GDAL team containing the two teams. gdal-admins has 9 members and the gdal-committers team has 22 members (our grass-subversion-committers legacy team has 33). gdal-admins has Admin for 2 repos and Write for 1 repo. gdal-committers Write for 2 repos. The top-level GDAL team has 5 direct members and 1 repo. The 3 repos are gdal, gdal-data, and shapelib (plus there is 1 auto-updated repo and 2 legacy repos not managed using access roles for teams). The two notable differences in the project structure influencing the number and diversity of repos are that the GDAL website is generated from the gdal repo and that GDAL drivers are either included in gdal repo, (inactive) legacy repo or in separate repos (GDAL has 1 Write team, we 3 extra teams). Additionally, we already had a need for a separate Triage team and a GitHub Discussion-managing Triage team (2 extra teams). We are not yet making use of the Maintain team (1 extra team).</div><div><br></div><div>More answers inline.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev <<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Ondrej,</div><div><br></div><div>I agree with you that there are too many teams for GRASS [1] and they should be consolidated (or not, but at least moved) as child teams.<br></div><div><br></div><div>Do we still need these subversion teams?<br></div><div><div>* <a id="m_6844258691068409107gmail-team-grass-subversion-committers" href="https://github.com/orgs/OSGeo/teams/grass-subversion-committers" target="_blank"><span>grass-subversion-committers</span></a>
<span>GRASS GIS Subversion committers</span></div><div></div></div><div>* <a id="m_6844258691068409107gmail-team-grass-addons-subversion-committers" href="https://github.com/orgs/OSGeo/teams/grass-addons-subversion-committers" target="_blank"><span>grass-addons-subversion-committers</span></a>
<span>GRASS GIS Addons Subversion committers</span></div></div></blockquote><div><br></div><div>These are people who had access in the Subversion times. We want these past Subversion-time
contributors to have Triage rights (whatever that means). The grass-addons repo works differently, so the Subversion-time group has Write access there, but that can be changed in the future easily as this group from pre-GitHub times is separate from the active group in grass-addons-write.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
</div><div><span></span></div><div><span>How is this team different from the above grass-addons-subversion-committers?<br></span></div><div><span>* </span><a id="m_6844258691068409107gmail-team-grass-addons-write" href="https://github.com/orgs/OSGeo/teams/grass-addons-write" target="_blank"><span>grass-addons-write</span></a>
<span>Maintainers of tools in GRASS GIS Addons with write access to the repository</span></div></div></blockquote><div><br></div><div>This is the active team where new people would be added. The Subversion team may move from Write to Triage in the future.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span></span></div><div><span>How are these three teams different?<br></span></div><div>*<span> </span><a id="m_6844258691068409107gmail-team-grass-admin" href="https://github.com/orgs/OSGeo/teams/grass-admin" target="_blank"><span>grass-admin</span></a>
<span>GRASS GIS repo administration team</span></div><div>* <a id="m_6844258691068409107gmail-team-grass-maintain" href="https://github.com/orgs/OSGeo/teams/grass-maintain" target="_blank"><span>grass-maintain</span></a>
<span>GRASS GIS repo settings maintenance team</span></div><div></div><div>* <a id="m_6844258691068409107gmail-team-grass-write" href="https://github.com/orgs/OSGeo/teams/grass-write" target="_blank"><span>grass-write</span></a>
<span>Maintainers of GRASS GIS with write access to the main repository</span> <br></div></div></blockquote><div><br></div><div>They have what GitHub calls Admin, Maintain, and Write access rights to the repo. Write is only for code. Maintain is for some of the settings. for Admin for access and security. See more here:<br></div><div><br></div><div><a href="https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization">https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div></div><div>I think we need this team.<br></div>* <a id="m_6844258691068409107gmail-team-grass-docker-homebrew-users" href="https://github.com/orgs/OSGeo/teams/grass-docker-homebrew-users" target="_blank"><span>grass-docker-homebrew-users</span></a>
<span>Users for automated dockerhub and homebrew builds</span></div></blockquote><div><br></div><div>I don't know why we have that. It works for notifications, but I haven't seen that used.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I believe we can consolidate these two teams.<br></div><div>* <a id="m_6844258691068409107gmail-team-grass-promo-write" href="https://github.com/orgs/OSGeo/teams/grass-promo-write" target="_blank"><span>grass-promo-write</span></a>
<span>Contributors to GRASS GIS promo repo with write access</span></div><div><div>* <a id="m_6844258691068409107gmail-team-grass-website-write" href="https://github.com/orgs/OSGeo/teams/grass-website-write" target="_blank"><span>grass-website-write</span></a>
<span>Maintainers of GRASS GIS website</span></div></div></div></blockquote><div><br></div><div>It is about access to potentially destructive actions. We may trust someone to manage a collection of materials in grass-promo, but we may want higher scrutiny for the grass-website repo which goes live after PR is merged.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>What about these two?<br></div><div><div>* <a id="m_6844258691068409107gmail-team-grass-discussion-moderators" href="https://github.com/orgs/OSGeo/teams/grass-discussion-moderators" target="_blank"><span>grass-discussion-moderators</span></a>
<span>Discussion moderators with general Triage access</span></div><div></div></div>* <a id="m_6844258691068409107gmail-team-grass-triage" href="https://github.com/orgs/OSGeo/teams/grass-triage" target="_blank"><span>grass-triage</span></a>
<span>Contributors with PR and issue triage power</span></div></div></blockquote><div><br></div><div>We created them in the past when the need arose. While they have the same Triage access (unpaid GitHub does not allow anything finer than that), they have different purposes. One is for moderating discussions and the other is for general triage of issues and PRs. Maybe an important note here is that to change an issue label, you need to have Triage access.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Best,</div><div>Huidae</div><div><br></div><div>[1] <a href="https://github.com/orgs/OSGeo/teams" target="_blank">https://github.com/orgs/OSGeo/teams</a></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev <<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sweet devs,<br>
<br>
Looking at the GitHub teams within the OSGeo organisation [1], it is<br>
impossible not to notice the fact that the GRASS people are very good<br>
in making themselves visible through visual weed infestation. On one<br>
side, it is nice to see GRASS all over the dance floor; on the other<br>
one, I don't find it particularly polite to storm the org and see that<br>
GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in<br>
total).<br></blockquote></div></blockquote><div><br></div><div>Is that a practical problem for anyone?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Wouldn't it be better to follow the example of GDAL instead?</blockquote></div></blockquote><div><br></div><div>I did explore the GDAL teams and repos and after a closer look I didn't find a specific model to follow nor anything particularly applicable to grass-* repos. Some of the comparison to GRASS situation is above.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Creating<br>
only one master team (grass) and then 11 child teams (grass-write,<br>
grass-addons-write, ...)? It would make the org team overview much<br>
cleaner.</blockquote></div></blockquote><div><br></div><div><div></div><div>Seeing how GDAL handles that, I didn't find team nesting particularly useful and we already had a couple of top-level teams.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, you could see all grass child teams' members in one<br>
place.<br></blockquote></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">That is still the only advantage I see, but then again, we already had several teams and I created the new ones on the same level.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In the name of New GitHub Order,<br>
Ondrej<br>
<br>
PS: I also believe that we should reduce the number of GRASS teams and<br>
consolidate some (grass-addons-subversion-committers -><br>
grass-addons-write) but I guess this is for another and much more<br>
contentious discussion.<br></blockquote></div></blockquote><div><br></div><div>The current number of teams is determined by the number of teams created in the past, some of them legacy, and by the number of repositories and the need to control write access to these repositories. I hope the above hopefully clarifies most of the reasoning behind the current teams.<br></div><div><br></div><div>Best,<br></div><div>Vaclav<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><div><div dir="ltr">Huidae Cho, Ph.D., GISP, /<a href="http://ipa-reader.xyz/?text=hid%C9%9B" target="_blank">hidɛ</a> t͡ɕo/, 조희대, 曺喜大</div><div dir="ltr">GRASS GIS Developer</div><div><a href="https://idea.isnew.info/" target="_blank">https://idea.isnew.info/</a><br></div></div></span></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div></div>