Re: [GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Hi there,

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

Re: [GRASS-dev] GRASS Teams on GitHub

[Even Rouault via grass-dev]

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 ;-)


Le 13/03/2024 à 01:35, Vaclav Petras via grass-dev a écrit :



On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek  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?


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.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


--
http://www.spatialys.com
My software is free, but my time generally not.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Vaclav Petras via grass-dev]

On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek  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?


> 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Hi again,

Sorry to start revive the conversation from the silence but I have the
feeling that it would be good to reach some consensus before we should
let it rest.

@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." 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).

Cheers from the discussion underworld,
Ondrej

čt 22. 2. 2024 v 9:35 odesílatel Ondřej Pešek  napsal:

>
> Sweet devs,
>
> Looking at the GitHub teams within the OSGeo organisation [1], it is
> impossible not to notice the fact that the GRASS people are very good
> in making themselves visible through visual weed infestation. On one
> side, it is nice to see GRASS all over the dance floor; on the other
> one, I don't find it particularly polite to storm the org and see that
> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
> total).
>
> Wouldn't it be better to follow the example of GDAL instead? Creating
> only one master team (grass) and then 11 child teams (grass-write,
> grass-addons-write, ...)? It would make the org team overview much
> cleaner. Also, you could see all grass child teams' members in one
> place.
>
> In the name of New GitHub Order,
> Ondrej
>
> PS: I also believe that we should reduce the number of GRASS teams and
> consolidate some (grass-addons-subversion-committers ->
> grass-addons-write) but I guess this is for another and much more
> contentious discussion.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Veronica Andreo via grass-dev]

Hello guys,

Thanks for this discussion. I went through all of your explanations and
reasoning, and while I agree we have more repos and hence the need for more
groups, I do think the GDAL teams structure gives a much better image of
structure, unity and organization than our loose groups all over the place.
As Ondrej says perhaps not many people go and check the OSGeo teams, but I
think the image we show to the rest and to ourselves is still important,
and these little details do make a difference in my opinion.

my 2 cents
Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Hi Vaclav, Huidae,

I was afraid of a long discussion (I know that the teams were changed
recently and expected the consolidation to need more talks) and that's
why I wanted to split it into two different threads: 1) master team
and child teams, 2) necessity of all the teams we have. But whatever,
let's then continue in both.

Before inline comments, let me say that I understand that we somehow
feel a "need" to have more teams than the other. I have never been
against that, only mentioning that maybe we don't need such a vast
number and that the master team would make it look nicer.

čt 22. 2. 2024 v 22:20 odesílatel Vaclav Petras  napsal:
> 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).

I would vote for getting rid of the legacy teams. I believe that the
subversion team members could be consolidated into grass-write and
grass-addons-write. I don't see any added value of the subversion ones
except for flexing with "I've been here before you". I don't have
anything against keeping those two separate as I see a difference in
the repo's nature - the fact that the users are almost the same is
just a current state and could change in the future.

I don't have a strong opinion on the need of extra grass-promo-write.
If you think it could be merged with grass-website-write, cool with me
but I see some meaning there (as you answered to Huidae, "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")

> We are not yet making use of the Maintain team (1 extra team).

Is there a plan for what it will be used? The members are the same as
of grass-admin. Is its purpose so different from the one of the admin
team?

> On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev 
>  wrote:
>>
>> Ondrej,
>>
>> 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.
>>
>> Do we still need these subversion teams?
>> * grass-subversion-committers GRASS GIS Subversion committers
>> * grass-addons-subversion-committers GRASS GIS Addons Subversion committers
>
>
> 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.

Isn't there grass-triage group for those whom we want to have Triage rights?

>> I think we need this team.
>> * grass-docker-homebrew-users Users for automated dockerhub and homebrew 
>> builds
>
>
> I don't know why we have that. It works for notifications, but I haven't seen 
> that used.

Another potential candidate for disintegration then?

>> On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev 
>>  wrote:
>>> Looking at the GitHub teams within the OSGeo organisation [1], it is
>>> impossible not to notice the fact that the GRASS people are very good
>>> in making themselves visible through visual weed infestation. On one
>>> side, it is nice to see GRASS all over the dance floor; on the other
>>> one, I don't find it particularly polite to storm the org and see that
>>> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
>>> total).
>
> Is that a practical problem for anyone?

Not being a practical problem does not mean it cannot be done in a better way.

>>>
>>> Creating
>>> only one master team (grass) and then 11 child teams (grass-write,
>>> grass-addons-write, ...)? It would make the org team overview much
>>> cleaner.
>
> Seeing how GDAL handles that, I didn't find team nesting particularly useful 
> and we already had a couple of top-level teams.
>
>>>
>>> Also, you could see all grass child teams' members in one
>>> place.
>
> 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.

I meant one master team not several ones.

I personally do find a structured way of storing information useful
(more than in an unstructured way). I like to know where I will find
the entire vegetable section in a shop instead of knowing just where
to find cauliflower and then wondering where to find other brassica
things. Also, you could then have a better idea from the OSGeo
organisation after the first look. Now it seems that most of OSGeo is
just GRASS. If GRASS was five times 

Re: [GRASS-dev] GRASS Teams on GitHub

[Vaclav Petras via grass-dev]

Huidae and Ondrej,

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).

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).

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).

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).

More answers inline.

On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Ondrej,
>
> 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.
>
> Do we still need these subversion teams?
> * grass-subversion-committers
>  GRASS
> GIS Subversion committers
> * grass-addons-subversion-committers
>  GRASS
> GIS Addons Subversion committers
>

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.


> How is this team different from the above
> grass-addons-subversion-committers?
> * grass-addons-write
>  Maintainers of
> tools in GRASS GIS Addons with write access to the repository
>

This is the active team where new people would be added. The Subversion
team may move from Write to Triage in the future.


> How are these three teams different?
> * grass-admin  GRASS GIS
> repo administration team
> * grass-maintain  GRASS
> GIS repo settings maintenance team
> * grass-write  Maintainers
> of GRASS GIS with write access to the main repository
>

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:

https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization


> I think we need this team.
> * 

Re: [GRASS-dev] GRASS Teams on GitHub

[Huidae Cho via grass-dev]

Ondrej,

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.

Do we still need these subversion teams?
* grass-subversion-committers
 GRASS GIS
Subversion committers
* grass-addons-subversion-committers
 GRASS
GIS Addons Subversion committers

How is this team different from the above
grass-addons-subversion-committers?
* grass-addons-write
 Maintainers of
tools in GRASS GIS Addons with write access to the repository

How are these three teams different?
* grass-admin  GRASS GIS
repo administration team
* grass-maintain  GRASS
GIS repo settings maintenance team
* grass-write  Maintainers
of GRASS GIS with write access to the main repository

I think we need this team.
* grass-docker-homebrew-users
 Users for
automated dockerhub and homebrew builds

I believe we can consolidate these two teams.
* grass-promo-write
 Contributors
to GRASS GIS promo repo with write access
* grass-website-write
 Maintainers of
GRASS GIS website

What about these two?
* grass-discussion-moderators
 Discussion
moderators with general Triage access
* grass-triage  Contributors
with PR and issue triage power

Best,
Huidae

[1] https://github.com/orgs/OSGeo/teams

On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Sweet devs,
>
> Looking at the GitHub teams within the OSGeo organisation [1], it is
> impossible not to notice the fact that the GRASS people are very good
> in making themselves visible through visual weed infestation. On one
> side, it is nice to see GRASS all over the dance floor; on the other
> one, I don't find it particularly polite to storm the org and see that
> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
> total).
>
> Wouldn't it be better to follow the example of GDAL instead? Creating
> only one master team (grass) and then 11 child teams (grass-write,
> grass-addons-write, ...)? It would make the org team overview much
> cleaner. Also, you could see all grass child teams' members in one
> place.
>
> In the name of New GitHub Order,
> Ondrej
>
> PS: I also believe that we should reduce the number of GRASS teams and
> consolidate some (grass-addons-subversion-committers ->
> grass-addons-write) but I guess this is for another and much more
> contentious discussion.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>


-- 
Huidae Cho, Ph.D., GISP, /hidɛ 
t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Sweet devs,

Looking at the GitHub teams within the OSGeo organisation [1], it is
impossible not to notice the fact that the GRASS people are very good
in making themselves visible through visual weed infestation. On one
side, it is nice to see GRASS all over the dance floor; on the other
one, I don't find it particularly polite to storm the org and see that
GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
total).

Wouldn't it be better to follow the example of GDAL instead? Creating
only one master team (grass) and then 11 child teams (grass-write,
grass-addons-write, ...)? It would make the org team overview much
cleaner. Also, you could see all grass child teams' members in one
place.

In the name of New GitHub Order,
Ondrej

PS: I also believe that we should reduce the number of GRASS teams and
consolidate some (grass-addons-subversion-committers ->
grass-addons-write) but I guess this is for another and much more
contentious discussion.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev