[GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek]

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 <wenzeslaus at gmail.com> 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 <grass-dev at 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.

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 <grass-dev at lists.osgeo.org> 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 in the overview of OSGeo projects
[1] and other ones just once, I can imagine everybody else being
upset. I guess it is not the case of GitHub only because so few people
dive into these depths but the thoughtful consideration should be the
same.

[1] https://www.osgeo.org/choose-a-project/analysis-and-processing/desktop-analysis/