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
