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.langa...@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/ > slanga...@ubuntu.com vor...@debian.org > -- > technical-board mailing list > technical-board@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
