Key Ubuntu teams should have an open process for new members
Lukasz Zemczak
lukasz.zemczak at canonical.com
Tue Jul 11 07:50:16 UTC 2023
Putting my very few cents into this discussion, however my general
views are very similar to those of Robie and Steve. It is a tough
topic, and it's even hard for me to formulate my own full-view opinion
here, as every idea I have has both pros and cons, and none of those
concepts that pop up in my head feels entirely right. As someone
that's part of most of the teams, my views can also be a bit biased,
but as a member of the Technical Board I'm really open to ideas and
suggestions.
Recently I started thinking of the release, archive-admin and SRU
teams more like 'executive teams' than decision making ones (really
more of a mix of both). The Technical Board did delegate some
decision-making power to those teams, but essentially their role is to
be the 'hand', the workforce, behind certain Ubuntu tasks. The
planning, decision making, feels more like what the Technical Board
does - along with all the Ubuntu Core Developers. But yes, there is
still some decisive power within these teams, especially when it's
about some fundamental changes to Ubuntu fundamentals, or when we're
talking about smaller things like feature-freeze exceptions etc.
I'm mentioning this as this is why I agree with Steve that this 'hard
time commitment' for members of these teams is so important. Because
of the nature of these teams, the time requirement is real and I
really don't know how to make sure this could be handled from the
outside.
I feel like we should be more open and approachable, but I don't know
if it's possible to make this an open process. I also think that the
nature of these teams makes it a bit hard to have an open membership
policy per-se. Teams such as release team, SRU team, archive admin
team - we don't have a set number of members at each moment, unlike
typical decision making teams like the TB and DMB. If we did, then we
could also have elections for certain members, although we still need
to remember what Steve said: the impact that the performance of these
teams, as they're 'executive teams' also, has on Canonical as a
business. So since this approach is not really feasible, the only
other way is to let this follow processes similar to what we have for
upload rights. But then this could basically lead to having 'too many
cooks in one kitchen', as even though their nature is a bit more
executive, there still is a lot decision-making power in these teams.
So I don't think this is feasible as well. I really don't see a
workable solution here.
This is certainly a good discussion to be having, so I'm happy that we
do. Maybe there will be some ideas/propositions here that will look
promising enough for the Technical Board to pick it up for
consideration.
One thing I'd like to make clear: even with things as they are now,
I'd like everyone to feel free and not be afraid of reaching out to
members of the aforementioned teams about membership opportunities. We
might not have open processes, but I'm sure members of each of the
teams will be more than willing to discuss membership, and no one will
be shot down instantly or ignored. Everyone's busy, but we're happy to
answer questions for sure - even if it takes a bit of time.
Cheers,
On Fri, 7 Jul 2023 at 23:56, Steve Langasek <steve.langasek at ubuntu.com> wrote:
>
> On Thu, Jul 06, 2023 at 04:08:07PM -0700, Erich Eickmeyer wrote:
> > On Wed, 2023-06-14 at 20:48 -0700, Steve Langasek wrote:
>
> > > To be clear, the Ubuntu Release Team has always been open to non-
> > > Canonical employees. I just don't expect community members of the
> > > Release Team to increase our "core" capacity.
>
> > I think that's a rather short-sighted expectation. If you have a
> > volunteer Release Team member that is passionate and sold-out for the
> > project, I think you'd be surprised as to what they'll accomplish.
>
> > Again, going back to my education, we're taught volunteerism.
> > Volunteers are in some ways easier to work with than employees, but in
> > some ways harder. When it comes to volunteers, you don't have a
> > paycheck to hold over their heads, so you have to cast the vision of
> > the project/organization to them often, especially if they're feeling
> > close to burnt-out. At the same time, if they need to take a break, you
> > have to let them. That said, they tend to be more passionate because
> > they're not doing it for a paycheck; they're doing it because it's the
> > thing they love. An army of volunteers is typically the most powerful
> > force in the world. So, don't ever underestimate community members.
>
> Driving a milestone is a two-week, full-time committment possibly in excess
> of 40 hours a week. Because Ubuntu releases are time-based, this work
> cannot be deferred or spread out as a result of other committments.
>
> I would not ask a community member of the Ubuntu Release Team, who is not
> being paid to do this work, to make such a committment. Even if someone did
> volunteer to do this, I do no think the Release Team should accept such an
> offer, as it's both exploitative of volunteer labor and unfairly places the
> volunteer in a position that, if they fail to deliver for any reason,
> impacts the business of Canonical.
>
> This is what I am referring to as "core" capacity.
>
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer https://www.debian.org/
> slangasek at ubuntu.com vorlon at debian.org
> --
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board
--
Ćukasz 'sil2100' Zemczak
Foundations Team
Tools Squad Interim Engineering Manager
lukasz.zemczak at canonical.com
www.canonical.com
More information about the technical-board
mailing list