Hi Technical Board, For what it's worth, I saw Seb's message when he sent it and we discussed it in private. I agree with every point he has made, and many of you know that I approach everything from a community-first perspective.
Additionally, if I seem to be wording something with aggressive undertones, please understand that's not the intention. If anything, it's urgent undertones. Also, I'm not demanding anything here, these are all suggestions from my perspective and education, which I'm freely sharing. I realize I'm not part of the technical board, nor am I part of the community council anymore, so I'm writing this as a flavor lead and community member at-large. I asked Seb if I should respond to this and we both thought it would be best after other members of the TB had time to respond, but he did agree that I should respond from my perspective. I fell ill in that time which gave plenty of time for TB members to respond and for me to formulate how I would like to respond. All of my responses are directed at everybody, so just because I'm responding to a particular quote doesn't mean I'm necessarily responding directly to that person. :) On Tue, 2023-06-13 at 20:46 +0100, Robie Basak wrote: > IMHO this is an important topic, since the CoC says "We invite > anybody, > from any company, to participate in any aspect of the project. Our > community is open, and any responsibility can be carried by any > contributor who demonstrates the required capacity and competence." > and > I think it would defeat the point of a community project to not have > this. > > However, I think an appropriate method depends on a team-by-team > basis, > and it would be reasonable for a team to decide that they don't > currently need any new members, or that some specific person isn't > currently suitably qualified to be on that team. If the team is > wrong, > then the TB would be the appropriate point to escalate; my point is > just > that if the team is right then I think that's a perfectly acceptable > situation from a governance perspective. While I agree with this, I have seen some fairly disturbing forms of gatekeeping lately, and while well-intentioned, we do need to be careful not to be blindly gatekeeping and favoriting. For example: On Wed, 2023-06-14 at 10:48 +0930, Alex Murray wrote: > On Tue, 2023-06-13 at 19:11:15 +0200, Sebastien Bacher wrote: > > 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 can't help but think that this (3 new members, all from > Foundations) > is either evidence of the (unintended) gate-keeping in action - > ie. since there is hardly any documentation on how to become a > release > team member in this case (https://wiki.ubuntu.com/ReleaseTeam has > nothing to say about this) the only way to become one is to be close > to > those who are already on the team - which is primarily foundations. > Or > perhaps it is just evidence that the foundations team are best placed > to > handle release team tasks etc. On Wed, 2023-06-14 at 13:44 -0700, Steve Langasek wrote: > As a member of the Release Team, the Foundations Team, and the > Technical > Board, I am trying not to be too biased or defensive here; if I miss > the > mark, please reel me in :) Unfortunately, despite Steve's reply, this does point to a bias since it seems as this is evidence that those on the Release team are originally from the Foundations team which means they work closest with the Foundations team. This means that, despite attempts to consciously put biases aside, members of the Foundations team will be favored since that's who is being worked with the most closely. It might be unintentional, but unless steps are taken to intentionally look in places other than Foundations (or other Canonical teams), it will unfortunately bias Canonical employees and especially the Foundations team by sheer proximity. I even question that certain people on the Foundations team are qualified to be on the Foundations team to begin with. People are being hired there that have no prior Ubuntu developer permissions and end up going before the DMB to get those permissions and often end up being denied on the first and subsequent tries. This likely means they have not worked with Ubuntu outside of programming or system administration. As a community member, I find this disturbing since this is potentially the future of the Release Team and possibly even the archive administrators, as the trend has shown from who is being brought-in to the Release Team. To be fair, this is a questioning of Canonical's recent hiring processes and biases more than anything. Bringing people to the key teams nearly exclusively from the Foundations team, whether intentional or not, is in contrast to Robie's very quote of the CoC above. I understand many of you see me as underqualified to even suggest this, but I can name at least two fully qualified Ubuntu community members who are not Canonical employees who would make excellent Release Team members, and one might even make an excellent AA. You might know who I'm talking about if you were as involved with the community as I am. What many of you don't know is that, despite being an Audio/Video/Photography person and now a bit of a programmer after five years of this, my degree is in leadership, so please let me speak on some authority on this subject. Like it or not, the Release Team, SRU Team, and Archive Admins are very much in leadership positions of the Ubuntu project from a technical perspective. In leadership, we are taught to be constantly looking to replace ourselves and mentor people to become our replacements. If you cannot do this, then you are not a true leader and your project (or organization) will die, and putting it off until tomorrow (procrastination) has the same effect. This means the onus for raising up new Release Team, SRU Team, or Archive Admins is on those people to teach others how to become members of those teams. Otherwise, it's a recipe for the entire Ubuntu project to die from the top down. None of us are going to live forever. The sooner these team members start to own this and start to actually do it the better. I don't mean to imply that every team member needs to do this, but certainly the most qualified leader of the group should. Being blunt: not having time isn't an excuse. If you're in the position you're in where you have to reproduce yourself in someone else (aka the leader), then you have to make the time. If a leader doesn't have this person, they should be actively looking for that person. I realize this isn't simple, but think of it as a job requirement, even if it's not explicitly listed in the description. It just comes with the territory of being a leader. On Wed, 2023-06-14 at 13:44 -0700, Steve Langasek wrote: > I don't know where that leaves us on the question of gatekeeping. > What do > you see that we could do to improve this process? In addition to everything I wrote above, the biggest thing these team members all need to do is stop looking at what's directly in front of them and start looking at the community-at-large. As I said before, there are many extremely compentent community members out there, and I can name two off the top of my head (I'm not referring to myself) that would make excellent Release Team members now, one of which would be an excellent Archive Admin. The biggest suggestions I can give you on that front is to take more time to be involved with the community and get to know them. A good chunk actually know what they're doing. 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. On Thu, 2023-06-15 at 14:21 +0930, Alex Murray wrote: > Ah ok, so then my suggestion would still be to document as much of > the > processes of the release team (and the other key Ubuntu teams) as > possible to ensure we make the barrier to entry as low as possible. > This > should also help anyone who thinks they would be a good candidate for > one of these teams to know in advance how they would measure up, as > they > could assess their understanding of these documented processes > against > their existing knowledge + experience. Documentation is good, especially on expectations, but the onus is still on the members of the key teams to be identifying and reaching out to people and mentoring them until they become those good candidates. People can say that they're interested, and it's good to look at those to see if they have the aptitude to be mentored to that capacity. Keep in mind, we can't always pick who we mentor; sometimes they pick us. On Tue, 2023-06-13 at 19:11:15 +0200, Sebastien Bacher wrote: > rs2009: am interested in joining the release team, but wasn't sure > how > to apply Here is a prime example of someone who is willing to and should be mentored. Rudra is not yet a core developer, but has not only the aptitude but is extremely promising and has the passion. Nobody should let this opportunity to mentor someone into the next generation of Ubuntu technical leadership pass them by. That onus is on everyone in the key teams. By the way, before someone talks about the Ubuntu Mentors team of old, I'm not talking about that at all. I'm talking about mentoring the next generation of these key teams specifically. If it's a matter of "ew, people", then your motivations are probably wrong. :) All this said, there's no simple solution to this, and I hope my suggestions don't fall on deaf ears or aren't rejected outright because "It's Erich and once again he has no idea what he's talking about" for lack of a better feeling. I do realize I'm on the outside of these teams (and these teams hold meetings away from public view, if they hold meetings at all), but: On Wed, 2023-06-14 at 18:21 +0100, Robie Basak wrote: > On Wed, Jun 14, 2023 at 01:17:01PM -0400, Jeremy Bícha wrote: > > On Wed, Jun 14, 2023 at 1:05 PM Robie Basak > > <robie.ba...@ubuntu.com> wrote: > > > But in general, I think we're doing OK, if you consider that a > > > reasonable rate for SRU team onboarding might be one or two a > > > year. > > > > The SRU team has only added one new member since the end of 2016 if > > I > > am reading this page correctly: > > https://launchpad.net/~ubuntu-sru/+members > > We started talking about adding new members around this time last > year > (15 Jul 2022 was the day I created a doc on it). That's not healthy. If there's nobody being mentored to take the place of somebody in any team, as attrition of some sort is inevitable, then the team is bound to die. Reacting to the loss of a team member, for any reason, rather than being proactive about it, is unhealthy for any team. That said, please utilize the community. Start building trust and let community members build trust. Don't let opportunities to mentor pass you by, and look for subtle hints. Get to know people and build relationships outside of your immediate circle. After all, doesn't all of this make a stronger Ubuntu? -- Erich Eickmeyer Project Leader - Ubuntu Studio Technical Lead - Edubuntu -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
