On Wed, Mar 9, 2022 at 11:00 AM Mattia Rizzolo <mapr...@ubuntu.com> wrote: > > On Tue, Mar 08, 2022 at 04:53:27PM -0500, Dan Streetman wrote: > > > * you say that the chair can be replaced at any time, but I propose that > > > such change require a supermajority (3/4th of the team) and since the > > > team is owned by the TB, that also needs to be accepted by them > > > > agreed on requiring TB approval - but I'm not sure about requiring a > > supermajority of votes? > > > > I feel like if a majority of team members aren't happy with the chair, > > then the chair probably should be replaced, no? And the TB will have > > final approval to keep or allow replacement of the chair. > > For taking down the current chair, yes simple majority. It just felt > more normal to me that the election of the one would require a stronger > majority than that, but if both of you don't think so, thats fine by me.
ah ok, i hadn't been thinking of separating chair removal from approving a new chair. I feel like it should be rather intentional for the team to be 'halted' from doing anything administrative as long as there's no chair (besides approving a new chair), so I was thinking that the removal of an existing chair would be tied to approving a new chair. It sounds like you're ok with leaving it as it is, but if you feel strongly I'm open to persuasion; although I will also add that I suspect if the situation ever arises that a chair would be approved by only a majority but not supermajority, there very likely would be enough animous in the team that some members would probably leave and/or the team would be dysfunctional in some other ways. > > > > * you haven't specified *who* can apply. I recommend to require MOTUs. > > > > i think we should move the specific membership requirements and > > process into simple team policies, don't you? there is the requirement > > in the charter for the team to document membership requirements and > > application process in our public docs. > > Not really, I think the set of membership requirements (at least when it > comes to the really strict requirements such as being an active dev > already) should be in the formal charter. > > Also a formal charter just saying "for more rules look at this > less-serious document" just sounds odd to me. > > If the only requirement we are writing down is 1) already member of a > team; 2) the current bpo team votes; then there is no need for an extra > document at all. Well, I think the reason for separating it from the charter is that specifics like this can change; for example, we may want to expand the team membership requirement, or add other requirements, or require a formal application wiki page, etc. If the specifics are in the charter, then we need to get TB approval for all changes; if it's just team policy changes, we don't need to wait for TB approval. Personally, I think TB approval should be restricted to only the most critical administrative functions of the team; if we need TB approval to change minute details of team administrative policies, I'm not sure what the point of having a charter is at all. In other words - the charter should lay out ONLY what and how the team will operate, in very broad terms. The details of the day-to-day operation of the team administration must be left to the team. To reverse the perspective on this - if the TB doesn't trust our team to decide on the specifics for managing membership, how can they possibly trust us to decide what should be accepted into the backports pocket? > > > re: MOTU, i agree, but also ~sru-developers I suggest? > > I'll admit that I've always found the concept of ~ubuntu-sru-developers > odd, I don't really get what's the point of it myself; I'd think > somebody interested in keeping up the stable releases should also > activily follow the dev releases.. plus the fact that looking at it it > feels (to me) a canonical-forced team just so that their employees can > bypass the sponsorship workflow :\ well, re: feeling ubuntu-sru-developers team is odd, I certainly join you in that boat. The team was created essentially by Robie as documented here: https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039652.html So yes, the team certainly was created in response to coredev applications by people from a specific canonical team (my team, btw). And it certainly is true that the vast majority of uploads from my team are to stable releases, not the development release; the entire point of our team is to 'sustain' ubuntu (hence, 'sustaining engineering team'). That's the primary reason I volunteered for the backports team; its main interest is to people who 'sustain' Ubuntu. Maybe that's the reason the backports team had problems in the past; it was driven by people who were *developing* Ubuntu, not *sustaining* it. Not everyone might realize it, but those are very, very different things. Does that mean the members of this team aren't capable of being coredevs? I'd like to think that's not true (although my path to becoming coredev was absolutely met with some..."resistance"...). Anyway, currently there are only 3 people on the team who aren't also coredev, and yes they are all from my team. I honestly would not expect anyone else to bother applying to the ubuntu-sru-developers team, at least not anyone outside of my team. I don't think any of them are actually interested, currently, in joining the backports team. So, the distinction is absolutely only theoretical at this point, and as long as we don't need to seek TB approval to expand the membership team requirement details, I have no problem leaving it off and requiring either coredev or motu. > > Having said all that, I still don't think it makes sense: I could accept > having that team be able to upload into the queue (I suspect their > uploads currently would just be rejected?), but like (I… think) they > can't be part of the ~ubuntu-sru team themeselves so to approve > them; that ought to require some kind of higher level in my mind. so the team naming certainly didn't help reduce confusion: The ~ubuntu-sru-developers team is the one where members can upload to stable releases, but can't upload to the development release. That's the only special ACL the team provides. The ~ubuntu-sru team is the team of people who can actually approve SRU uploads in the queues, and it is not controlled by the DMB; it's an invite-only team. So members of the ~ubuntu-sru-developers team are who I'm suggesting we allow (in addition to coredev and motu). Those members can already upload a package into the backports queues; since there is no backport queue for the development release, the ~ubuntu-sru-developers team has essentially the exact same ACL as coredevs, as far as the -backport pocket. Anyway, it's all rather confusing and honestly probably unnecessary, and absolutely theoretical at this point, so let's just leave it off and require coredev or motu. Oh and just to confuse things even more, *technically* there is no ACL distinction between coredevs and ~ubuntu-sru-developers; launchpad doesn't have appropriate ACL controls to prevent members of ~ubuntu-sru-developers from uploading to the development release, so members of that team are just 'trusted' not to upload to the development release. Sigh. > > TBH I already feel odd myself being able to deal with packages in main > while being only a MOTU for now.... lol, put your coredev application on the agenda asap...sometimes it takes a while to actually get enough votes together! > > > > > * what's with the "may 1st" thing about the chair? especially if > > > somebody is "promoted" to chair, that would make for an awkward > > > situation, so what's the reason behind that? > > > * so you think we should vote to extend everybody's membership? That > > > sounds like too much work, wouldn't it? also I don't really see a > > > need for it. And if you think it'd be useful, then everybody should > > > expire the same date so that we can just hold one yearly meeting > > > renewing (or not) everybody at once. > > > > yeah all this isn't needed for our team - i was thinking more of > > issues with some other teams. > > Alright, so… you dropped all changes related to expiry. > > I think something should stay. Like make the members expire yearly and > having them to renew themeselves. > > FTR, I consider the current "Any team member may call for a public vote > to remove any other team member." fine as a way to remove inactive > people from the board. We can then police ourseleves whenever we feel > like the inactivity of somebody is causing trouble. yeah this was my thought as well; i'll add back in 1 year expiry with self-renew. totally agree that as long as the team can easily vote to remove inactive members there's no need for stricter expiry. > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- > -- > ubuntu-backports mailing list > ubuntu-backports@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
