Team charter

[Mattia Rizzolo]

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.

> > * 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.

> 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 :\

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.

TBH I already feel odd myself being able to deal with packages in main
while being only a MOTU for now....


> > * 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.

-- 
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  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-backports/attachments/20220309/7e721eb2/attachment.sig>