Date: Mon, 8 Jun 2020 12:46:53 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Rasmus Thomsen <oss@cogitri.dev>
Cc: Ariadne Conill  <ariadne@dereferenced.org>,
 ~alpine/devel@lists.alpinelinux.org
Subject: Re: team-maintained packages
Message-ID: <20200608124653.009172bf@ncopa-desktop.copa.dup.pw>
In-Reply-To: <7a0647b48d615b4f61f776c3e34374f50c61b85e.camel@cogitri.dev>
References: <1765542.52O7J0OIYB@localhost>
	<20200608105947.39003711@ncopa-desktop.copa.dup.pw>
	<7a0647b48d615b4f61f776c3e34374f50c61b85e.camel@cogitri.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 08 Jun 2020 11:12:13 +0200
Rasmus Thomsen <oss@cogitri.dev> wrote:

> On Mon, 2020-06-08 at 10:59 +0200, Natanael Copa wrote:
> > On Mon, 08 Jun 2020 02:13:49 -0600
> > Ariadne Conill <ariadne@dereferenced.org> wrote:
> > 
> > [...]
> >   
> > > > From an APKBUILD perspective, the maintainer line would look like
> > > > this:    
> > > 
> > > # Maintainer: Alpine KDE team <  
> > > https://gitlab.alpinelinux.org/groups/kde>  
> > > # Coordinator: Whoever <whoever@alpinelinux.org>
> > > 
> > > The "coordinator" role would be the preferred member in the group
> > > for contact 
> > > about the package, but the team as a whole could also make
> > > decisions about the 
> > > package as well.  
> > 
> > I like the idea. The thing I am mostly worried about is when everyone
> > on the team thinks that someone else will take care of an incoming
> > issue, resulting in nobody doing it. I think that a "coordinator"
> > role
> > for each team solves that.  
> 
> Isn't the idea to have teams so that everyone can look at any APKBUILD
> the team maintains when they have time/feel like it? 

Sure.

> I think that:
> 
> 1) We'll have a hard time finding people with enough time to coordinate
> a team.
> 2) We'll place too much workload on the coordinator instead of just
> distributing the load across all members of the teams.

I don't think the teams will be bigger than 1-2 initially so there will
not be any coordination work. But it will prepare us to scale. It will
also serve as a form of documentation on who takes care of what.

But I agree, we don't want needless administrative work.

> Also, I'm not quite sure what the coordinator would do. They could
> poke someone from the team they think could review the MR, but if that
> person were interested in reviewing the MR they'd probably do so when
> they get the email for the team-ping on that MR. So the coordinator
> would either end up reviewing the MR (defeating the point of the team)
> or would have to poke indiviuals who really should just look at the
> team notifications if they're interested in being in the team.

I think anyone in the team could review and merge the MRs if the teams
wants that. I also support that even people who are not on the team
should be able to review and merge MRs, like we do now.

Coordinators role would be to have overview and be a communication
point for the team. A contributor wants to help with something, lets
say documentation, and it is known that there are 2 other people
working on it too. Who should the contributor speak with to avoid
double work? The coordinator.

I expect the coordinator role be nothing more than a name in the
documentation of who is doing what initially, but the role will be more
significant as the size of the team increases.

-nc