[TEAM] Proposal for the Xubuntu Council

[Pasi Lallinaho]

On 2016-05-16 00:46, Simon Steinbeiss wrote:
> Hi everyone,
>
> first of all thanks to Pasi and Kev to formulating and sharing the 
> proposal.
> My comments follow inline.
>
> Cheers
> Simon
>
> ------------------------------------------------------------------------
> > Hello,
> >
> > after a brief private discussion within the Xubuntu team, the team has
> > decided to pursue setting up a Xubuntu Council instead of electing a new
> > Xubuntu Project Lead.
> >
> > After this discussion, myself and Kev have been drafting a proposal for
> > the council. Here it is in a nutshell.
> >
> > ==
> >
> > WHAT IS THE XUBUNTU COUNCIL?
> > – The Xubuntu Council (later: council) will replace the Xubuntu Project
> > Lead (later: XPL) position.
> > –A council term is2 years, always ending after an LTS release to allow
> > long-term planning.
> >
> > COUNCIL MEMBERS
> > – The council will consist of 3 members.
> > – The members will be elected based on a CIVS [1] vote.
> > – Anybody who is a member of the Xubuntu team [2] or a *direct* member
> > of any of the moderated subteams [3] can nominate themselves,or be
> > nominated bysomeoneelse with the candidates agreement.//>  – Everybody who is member of the Xubuntu team [2] and/or a *direct*
> > member of any of the moderated subteams [3] can vote.
>
> Just to be sure, but *direct* is meant to exlcude indirect members 
> like other Ubuntu teams that are members of some of our teams (like 
> "Ubuntu Core Devs" as part of "Xubuntu Devs")?

Indeed, we're simply excluding these teams that technically have to be 
part of the teams.

> > – If a council member goes missing in action for 6 months, they should
> > be replaced by a new vote.
> We sort of have that now even for team members, but so far we're not 
> executing this very thoroughly (I'd like to think that for my period 
> "in office" I tried to trigger these decisions with considerately). I 
> wonder whether the "should" is enough here and whether we'd like to 
> stick to the approach that I myself followed or whether we just want 
> to set an expiry date instead (which would shift the trigger from 
> being excluded to remaining included).

Yes, this is designed to be the same as with team members.

The reason why I think it matters more with the Council is that one 
member dropping leaves the Council with two active members, which in 
turn means in case they need to resolve something, they don't have a 
tie-breaker, and also means more work for those members, if there is any.

I'd rather make sure we always have the three-member Council ready 
instead of having to either cope with the two-member one or elect a new 
member *if* the Council needs to take action.

> > – If a new council member is elected mid-term, their term will still end
> > after the next LTS release.
> >
> > COUNCIL CHAIR
> > – The council will decide on a chair whose term will last for the whole
> > council term.
>
> Wouldn't it alternatively make sense to give the council the freedom 
> to split the chair? So far one of the issues of finding an XPL was the 
> 2year commitment of a single person and this point goes a bit in that 
> direction. I'd rather have the council as an elected body for two 
> years and the council always has to have a chair/spokesperson, but who 
> that is is up to the council, not another general vote.

As the point implies, it *is* up to the council to decide the chair.

I did also propose splitting the chair terms up to for example two 
one-year terms within the cycle. I still think this is a fair option, 
given that the council is fine with it.

That said, one of the reasons for proposing this instead of something 
else is the next point: the council chair is a natural point-of-contact 
(like the XPL is). Of course they can delegate stuff that arises from 
being the PoC to other council members.

> > – The chair will act as the official point of contact for Xubuntu.
> > –If the council chair wishes to relinquish chair, a new chair is chosen
> > as members (see above).
> >
> > OTHER BITS
> > – The council is expected to take action,or respond to any issue within 2
> > weeks; if appropriate and fair, the first action can be postponement.
>
> How often can the council postpone and for how long? (Or do we expect 
> that it'll always be "within reason"?) Also, I'd add that 
> "postponement" has to be explicit, not implicit (by not re/acting).

Indeed, the postponement needs to be explicit and include the reasoning 
why the issue at hand is postponed.

I'd expect that we would mostly see postponement that is within reason; 
if it's not, then team members who are waiting for actions/comments 
should ask the council to reconsider. If the team and the council can't 
reach an agreement (which I doubt TBH), then the following point works 
for that as well: the CC acts as a final arbiter.

> > – If the council fails to reach consensus on an issue, the Ubuntu
> > Community Council acts as the final arbiter.
>
> Why not a general vote of the xubuntu-team? Or would you say the 
> council mainly acts as a tie-breaker for the team votes? That is not 
> to say that I think that the Ubuntu CC is not a good final last resort.

Indeed, if an issue needs to be raised to the council, then it more or 
less implies the team is not reaching consensus either. Of course that 
doesn't mean they are in a situation where CC intervention is needed either.

It's probably a good idea to mention in the XSD section that the council 
is indeed expected to try to resolve the issue with all means they can; 
not only voting between the three, but also gathering all the 
information and after that conducting a new team vote etc. Only after 
they have tried everything they can should they consult the CC.

> > [1]http://civs.cs.cornell.edu/
> > [2] ~xubuntu-team on Launchpad
> > [3] ~xubuntu-release, ~xubuntu-dev, ~xubuntu-art, ~xubuntu-website,
> > ~xubuntu-qa, ~xubuntu-doc on Launchpad
> >
> > ==
> >
> > Note that while the proposal only allows people in moderated teams to be
> > nominated and vote, those moderated teams are open to anyone to join -
> > via sustained contributions to the project.
>
> Yes, and I think that is a "nice" (as in: "suitable" or "meaningful") mix of open and moderated.
>
> > As an example, the QA team (~xubuntu-qa) was set up for these kinds of
> > social reasons; the team expects people from the testers team
> > (~xubuntu-testers) to be approved to the QA team once they have shown
> > sustained/substantial contributions enough.
> >
> > In the same spirit, we're discussing the possibility to set up other
> > teams that have a similar social aspect.
> >
> > TEAM MEMBERS, please reply with comments on this proposal. I'm pretty
> > sure this isn't the final version of what we want to vote on, so please
> > do commenting rather sooner than later.
> >
> > Once we've voted on (and hopefully approved) a certain direction, we
> > still need to at least formulate that into a section of the Xubuntu
> > Strategy Document and run it through the Ubuntu Community Council. All
> > of the work items are in a Launchpad blueprint [4].
> >
> > Cheers,
> > Pasi
>
> > [4]https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-y-council
>
>

Cheers,
Pasi

-- 
Pasi Lallinaho (knome)                » http://open.knome.fi/
Leader of Shimmer Project             » http://shimmerproject.org/
Ubuntu member, Xubuntu Website Lead   » http://xubuntu.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/xubuntu-devel/attachments/20160516/e1c76303/attachment.html>