On 3/14/2019 12:11 PM, Natanael Copa wrote:
> This has been suggested before. Wilcox had some good points and
I agree with the following points:
- People can often identify with their specific project even moreso than
with the distribution.
- Having dedicated teams for languages - this isn't necessary, but is
very useful when there is sufficient interest.
However, I have several issues with the idea being presented there.
- Some level of formality is needed - this helps avoid a bottlenecking
situation, and enforces separation of tasks (minimizing
context-switching and thus increasing total throughput).
- A license-oriented team likely isn't needed per-se. We have since
started using the SPDX license list, so the remaining bits can be
handled by the core and aports teams (depending on the specifics).
The reality is that that suggestion was made in the middle of 2017, and
the situation has changed, but it's certainly something to look at.
> And we need this badly. We are not lacking volunteers, but problem is
> that I have become in a position that everything blocks on me. I want
> fix that.
It also means that you (and other core/infra developers) tend to be
One of the goals would be to lessen your load (and allow you to, at the
same time, be more efficient at the things that you *do* still do :) ).
> What would be the simplest way to get this started? We already have a
> semi-team for infra, with Carlo as team lead.
> We could probably also get a docs team running immediately, with Chloe
> as team lead.
> That would be a good start I think.
Currently, the plan (as discussed in #alpine-docs, because that's where
the conversation happened to have happened) is to have a meeting on
Sunday, 14:00 GMT.
I'm currently composing a proposed agenda for it.
During it, things such as the initial teams should be decided, after
which (likely Monday) a final version would be submitted for approval by
the core team.
Once approval happens, I'll initialize a developer-handbook repository
(even if it'll likely be a bit until more things get added to it) and
populate it with everything that'll have been decided during the meeting
(and potentially revised during the, hopefully short, approval process).
As a side note, I agree with your initial set of teams, though I think
the core and aport teams should also be made at the start, along with a
full member listing.
Received on Thu Mar 14 2019 - 20:16:00 UTC