Hello Technical Board,
At the request of the current Technical Board, I'm reopening this thread
in light of new and related questions. Forgive my top-posting as my
intent here is to start a new - but related - conversation about this.
Also, please forgive my past communication style related to this. I have
learned a lot about myself in the past year with regards to how I
operate and how my brain is wired. I'm trying to be on better footing
here and hope that the way I had communicated on this thread might be
overlooked. I do regret my past approach.
In any event, the reason I'm bringing this back up is because I have
seen at least one appointment to the SRU team from which there was very
little, if any, prior interaction with the community. Looking up this
person's Launchpad account, I determined that they weren't a Core
Developer or MOTU but an SRU Developer, which is in my recollection a
new developer category introduced by the DMB? I could be wrong. But, in
any event, I've seen numerous other SRU Developer applications pop-up on
Discourse, which raises the question as to if this is essentially an
easier way to get what would previously be the same privileges as a MOTU
or Core Developer but for release updates only.
I would like to applaud the SRU Team for finally documenting their
eligibility requirements at
https://ubuntu.com/project/docs/SRU/internal/#criteria-for-new-sru-team-members.
However, to quote from those requirements:
Must be able to upload all SRUs they expect to review; i.e. Ubuntu
Core Developer or SRU Developer. A member of the SRU team who is an
SRU Developer is expected to be in the process of applying to be an
Ubuntu Core Developer: the role involves exercising judgement about
whether a change in the development series is*good*, and therefore
someone in this role should be formally trusted by the project to
make such decisions for the development series as well.
The SRU team is largely a community-facing team since any MOTU, Core
Developer, and presumably (?) SRU Developer can upload or sponsor an
SRU. However, if an SRU Team member reviews an SRU without having
built-up that rapport, that can be problematic in how it is handled.
Granted, we "assume good intentions", but I, for one, would be more
comfortable if a member of the SRU team was at least a MOTU or Core
Developer before being appointed. I don't think "SRU Developer ...
expected to be in the process of applying to be an Ubuntu Core
Developer" is enough to be entrusted.
Instead, what I'm seeing is SRU members are being appointed from
Canonical employees exclusively. Being a Canonical employee, per the
link above, is not a requirement (or even prerequisite) of being on the
SRU team. To make that a prerequisite would be a violation of the Code
of Conduct per what was discussed previously in this thread. However, I
do see that the trend stands that SRU Team members are still composed
exclusively of Canonical and formerly Canonical employees, who were with
Canonical at the time of their appointments.
Same is also true for the Archive Admins and the Release Team, which
have still, over three years later, to my knowledge, not documented
their eligibility requirements.
Steve Langasek had stated previously that it only makes sense for these
teams to be hand-picking from the people they work with. However, that's
still in-effect the exact same situation as if the eligibility for these
teams were to be composed of Canonical employees exclusively at the time
of their appointments. Furthermore, these processes are usually done
"behind closed doors" which raises a credibility issue in a system where
we're supposed to do things in the open.
I'm advocating for more appointments from the community for several
reasons. For instance, it's hard to show that we're abiding by the Code
of Conduct without showing it by who we allow to be involved in certain
parts of the project. Additionally, creating more avenues for people to
be involved where they might be interested helps to create opportunities
for inclusion. It can also prevent burnout by letting people contribute
where they might be passionate. The key things to look for is aptitude,
proficiency, and passion. This can only happen when people are actively
involved. This would have a benefit of certain things being able to be
done outside of certain Canonical employee holidays. Of course, this is
only the tip of the iceberg where it comes to this advocacy that I have.
I do want to state that I'm writing all this not as a flavor lead, so
don't read any of that into it. For instance, I don't believe that
anything needs to change with regards to established processes with
regards to new packages, repository maintenance, SRUs, releases, etc,
nor that I want any more entrusted to the flavors with regards to these
processes. My communication style tends to be very literal, as many of
you know, so don't read motivations into it other than what I have stated.
In summary, what I think we need to see is more hand-picking of people
outside of Canonical, or an application process for those who want to
volunteer. Remember, Canonical isn't the only organization where people
are paid to work on Ubuntu. Also, some teams still need to document
their eligibility requirements as this has not happened over three years
later. Additionally, those that are chosen should have a certain amount
of community involvement as they will be interacting with the community
frequently.
Thanks for your time. Hope those of you with Canonical are having a good
break!
Erich
On 6/13/23 10:11, Sebastien Bacher wrote:
(for context that's an email I sent the techboard before I joined the
board, the discussion picked up recently and TB members agreed that we
should have it on the mailing list)
Dear Technical Board,
I would like to bring that topic for consideration. I believe that the
lack of open application process for core Ubuntu teams (Archive Admin,
Release Team, SRU team) is hurting the project and has lead to an
ongoing under-staffing of those groups.
I'm unsure how to best approach the topic so I'm going to list a few
examples of situations I've witnessed or experienced and found
problematic.
1. Could be an obvious one but the Archive and SRU teams don't have
defined contact points, which makes quite difficult for anyone to
engage with them. You can't try to IRC ping and hope someone reply but
it is not great
2. Laney's application to become Archive Admin
The core teams members are usually quite busy people. That's a topic
that is coming on regular basis as people try to restore some sort of
on-duty-rotation for the members, which has not had much success in
recent years.
Iain proposed to join the ~ubuntu-archive team to help in early 2020.
We had a in person discussion with several of the archive admins in
Frankfurt in March at a Canonical event where everyone agreed that
Iain is trusted and should be added, yet we couldn't move to the next
step since there is no documented process to follow. Since we were a
bit lost on how to get that moving I sent a group email end of June
asking us to vote on adding Iain hoping it would unblock the
situation. We got most people replying with a +1 position, then Steve
replied by requesting that Iain got trained with an existing archive
admin on specific tasks before being added. He also added that
'Regarding process: the de facto process up to now has been that you
convince one of the administrators of the ~ubuntu-archive team, and
you're in.'
3. Christian Ehrhardt applied to join the Archive team as well this
year, he started by emailing me/a few others with an emailed titled
'What does it take to become an Archive-Admin?'
which included those questions
'That made me wonder what exactly it would take to become an
ArchiveAdmin myself.
There are plenty of docs about how to become a CoreDev or any of the
lower tier upload permissions. But the ArchiveAdmin role seems to be
freestyle - at least from what I can tell from the Wiki.
Thereby I was wondering - and hereby asking you - about:
- Are there things considered a strict requirement or qualification to
become an AA?
- Is there a formal process to become an Archive Admin?
- Are there regular rotations on AA-tasks like NBS, New queue, ...?
- if so how much time per week is expected/required?'
To which he got as a reply
'So the Archive Admin team, similarly to the Ubuntu SRU and Ubuntu
Release teams, is a strict invite-only team with no formal process of
becoming one. The main reason is that being an AA gives a lot of power
in Ubuntu, basically giving full control over the Ubuntu archive
as-is, so it's not something anyone can get by just requesting
membership. This is also why there is no formal process as we do not
want it to be possible for arbitrary people to apply by themselves.'
That's not the first time I hear that position and I don't believe the
claim to be true. I don't see how having an open process would lower
the bar? The same people would take the decision of who is getting
added. The application could go through a private list if needed. I
also don't believe that we would have such a flow of low qualified
applicants.
4. Those teams are understaffed and it is problematic for the project.
Random recent quotes from IRC
https://irclogs.ubuntu.com/2022/10/06/%23ubuntu-release.html#t09:28
GunnarHj The kinetic unapproved queue is longer than I would have
expected a week before Final Freeze. Specifically gnome-user-docs is a
concern of mine, but there are quite a few others. Is there a plan to
attend to the queue soon? 09:28
xnox GunnarHj: i think a few release team people are out.
...
Eickmeyer[m]ginggs: I'm confused too. AIUI, the release team
(partially meaning you) is supposed to be processing the unapproved
queue this time of the release cycle. It hasn't budged all week.
...
rs2009: am interested in joining the release team, but wasn't sure how
to apply
https://irclogs.ubuntu.com/2022/10/17/%23ubuntu-devel.html
pitti: what's up with SRUs? looks like the jammy queue hasn't been
processed since mid-August?
5. Another anecdotal fact,
https://launchpad.net/~ubuntu-release/+members shows only 3 members
added in the last 6 years and they are all coming from the Canonical
Foundation team.
I've been told one new member is being onboarded which isn't from
Foundations (but from another Canonical team) but I don't think that
change the picture and it does look like people wanting their group to
be the only ones to have control and reflect bad on the project
(unless you believe we don't have members outside of
Canonical-foundations that would be suited for the job or wanting to
do it, which I don't think is true)
I've been talking to members of those teams and their admin over the
years and I don't believe they are interested in seeing more openness
in the process which I why I'm bringing the topic to the TB at this
point. I'm happy to provide more examples or to discuss the situation
directly with TB members if needed.
Also as a disclosure, I find the lack of manpower and the review
delays from those teams problematic and I tried to proposed my help to
the SRU team several times in the past in private conversation with
current members who seemed to be open to the idea to never hear back.
We also tried to get someone from ~ubuntu-desktop added to the release
group after Laney left Canonical and had less time to contribute to
hit a similar walls.
I'm busy enough and already member of other key teams and I might not
been the right applicant for those but I would have like to at least
have someone tell me that because at this point I still don't know if
the idea of having me helping got rejected or not considered? And if
it was not if that's because of the lack of process which means we
just end up in a situation where those teams don't even realize that
the project has some members that would be wanted to help?
I've also to admit the situation has made me wonder a few times in the
recent cycles if I should reconsider my involvement in the project
Thanks for reading,
Sebastien Bacher
--
technical-board mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/technical-board
