Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Blosser (emrys) wrote:
> So, it's time to pick this thread up again.  :-)  If you're one of the
> people that hates the "political" discussion, the good news is that there's
> a proposal in here to let you just hack and not have to worry about this
> stuff again.  The bad news is you may want to read just a bit more so you
> can decide if you agree or not.
> 
> ===========================================================================
> 
> Over the last few months (and longer), several issues related to project
> organization have been raised.  These include:
> 
> - are we organized the best way to get our work done?
> - we need more redundancy among the identified leaders/owners of components
>   and deadlines
> - we have more teams than we have people
> - some people wish more things had votes
> - some people wish nothing had votes
> - some people don't care what has a vote as long as they don't have to be
>   involved and can just hack
> - our [PT]L votes are closed, some people don't like this, but some people
>   "need" it
> - our [PT]L votes lack auditability because of how the closed vote is
>   implemented
> - our voting guidelines tend to get fudged and we're lazy about various
>   things 
> - etc.
> 
> We had some decent discussion on this thread, but several people were
> complaining about the "political noise" on the ML, and other things came
> up, so it mostly stopped.  Then the issues continued to come up on things
> like the Project and Grimoire TL votes, etc.  I went ahead and put together
> a formal proposal on how I think we could perhaps do things better, which
> I'm attaching here.  I went ahead and ran this by the TLs already and they
> mostly seem to think it's a good idea, so I think it's time to bring the
> thread back and see if we can finish it off.  If you reread the bit quoted
> below, which met with general agreement on the ML, this is the main idea I
> went for.
> 
> Under this proposal, the following things would *NOT* change:
> 
> - we would still have one project lead
> - we would still have individual elected leads over major components like
>   cauldron, grimoire, sorcery, tome
> - all developers would still be eligible to vote for all of the above leads
>   once per year
> - the lead votes would still be closed
> - other issues facing the project would be decided by a vote of the leads
>   only
> - these 'issue votes' by the leads would still be cast in the open (they
>   are open when they happen now, though they are rare and essentially
>   undefined)
> 
> The following things WOULD change:
> 
> - developers that didn't want to participate in votes and issues wouldn't
>   have to
> - the process for voting on issues would be defined and hopefully used more
>   often
> - there would be a process for the general developer population to veto
>   anything the leads decided
> - more developers would be able to be leads than just the team and project
>   leads
> - the developer "teams" would be replaced with just one group of
>   developers, and the "Team Leads" would become "Component Leads" instead
> 
> Those last two are the biggest changes, so they deserve some discussion.
> Both are mostly meant to deal with the "we have more teams than people"
> issue:
> 
>> - more developers would be able to be leads than just the team and
>>   project leads
> 
> The goal here is stop the trend to create a team just because we have
> someone we want to make a lead.  We have developers that just want to hack
> on their stuff, but we also have some that want to help with things like
> goals and overall project issues and such.  There's no reason to make them
> try to fit into a team lead position (or create a new team for them to
> lead) just so they can get involved at that level.  Also, having more leads
> will let the leads hand things off between each other more easily so that
> if someone is gone, someone else can pick up for them with less of an
> authorization question.
> 
>> - the developer "teams" would be replaced with just one group of
>>   developers, and the "Team Leads" would become "Component Leads" instead
> 
> Right now it's really only the Grimoire Team that ever has more members
> than "the Lead and someone else".  And the members of those other teams
> tend to move around between components a lot anyway, just doing the work
> that needs doing.  We can encourage this more by just acknowledging this is
> how we really work in the official organization, so that if one
> person/group is mostly busy elsewhere for a while other people can easily
> work on what needs to get done so the project can move forward.  Again,
> this is mostly what's discussed in the bit quoted below.  The organization
> would be:
> 
> Project Lead
> |
> |-> Lead Team
>     |-> Cauldron Lead
>     |-> Grimoire Lead
>     |-> Sorcery Lead
>     |-> Tome Lead
>     |-> General Leads
> |
> |-> General Developers
> 
> That's the summary of this proposal, and I think it's accurate.  The full
> docs are attached.  Like Sergey I have some admiration for the voting
> methods the Apache project pioneered, so you'll see some of their terms in
> there, hopefully they're mostly familiar to most of you.  If not, there's a
> URL in there with some general definitions.  If any of it doesn't make
> sense please say so.  I'm hoping this is all seen as a good thing and
> something we should do, but if not then let's talk about it.
> 
> I want to give some time for discussion on this, then depending on how it's
> received I'll suggest it move forward based on the process it defines
> itself: a motion, hopefully a second, and then a vote by the existing
> Project and Team Leads.  Whether it passes or fails, the non-Lead
> developers would then have the option to veto the Lead vote.  This is a
> major change in some ways, so we should know there's agreement before we
> use it or decide to drop it, and that process seems at least a decent way
> to determine that.
> 
> On Feb 15, Eric Sandall [eric AT sandall.us] wrote:
>> On Tue, 14 Feb 2006, Jeremy Blosser (emrys) wrote:
>>> A possible arrangement based on the above would be something where we keep
>>> the TLs, but not the teams... make the TLs component leads or something
>>> instead, or the "council of elders" idea but with a PL still over them.
>>> Basically, have the majority of developers that work on spells continue to
>>> do that, then have a tier of more "free agent" types who are working on 
>>> the
>>> hairier stuff, then from that group have specific leads identified so we
>>> continue to have ownership and oversight of the major areas instead of
>>> anarchy, then a PL over them.  This arrangement would be very similar to
>>> what we have now except it would allow various team members to move more
>>> freely between projects as they're needed or want to, and would put a bit
>>> more responsibilty on the leads to make sure their areas were progressing
>>> toward their goals.  I'm mostly making this up as I type it, but it seems
>>> like it might describe the kind of thing that happens naturally now.
>>> Acknowledging it and actively supporting it might find us spending less
>>> time spinning wheels and more time getting things done.
>> That's a good point. So we'd have more this structure?
>>    Project Lead
>>    |-> Cauldron Lead (Porting would probably move here)
>>    |-> Grimoire Lead
>>    |-> QA Lead (with Security being moved under here)
>>    |-> Sorcery Lead
>>    |-> Tome Lead (with PR being moved under here)
>>    |-> Developers
>>
>> That makes 5 "Teams" under the Project Lead and a group of Developers
>> open for assignment, with each Lead being responsible for their components
>> (e.g. Cauldron in charge of producing installers (e.g. ISOs)) and 
>> organizing
>> (through mailing lists, forums, and/or IRC) the "Developers" group, where 
>> any
>> Developer can work on any component (given they have permission from
>> the Lead of that component) and not being tied to any specific team.
>>
>> I would still like the Grimoire Team to have section maintainers, but
>> perhaps that could be, again, people from the Developers group asking
>> the Grimoire Lead if they can maintain a section, and if Arwed says
>> okay, then that Developer can add themselves to the MAINTAINER file of
>> that section.
>>
>> Anyone see problems with this? Shall we go ahead and do this?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Developer Organization
> ======================
> 
> SMGL's contributors are organized into a team of Lead Developers* and a 
> team of
> General Developers*.  Leads are further divided into a Project Lead, 
> identified
> Component Leads, and General Leads.  The Project and Component Leads may 
> also
> have Assistants.
> 
> [*For the purposes of this policy discussion we will refer to them using 
> these
> names; "Council of Elders" and "Council of Developers" has been suggested 
> as a
> an alternate name, but we'll let that sit for now and discuss the policy
> details instead.]
> 
> General Developrs: 
> - are defined as all non-Lead Developers listed at:
>   http://www.sourcemage.org/developers
> - can be added to the project and given repository access by any Lead
>   Developer.
> - have commit access to the various project components, at the discretion of
>   the Lead over that component.
> - have the option to cast a binding vote in all Lead Election votes.
> - have the option to cast a non-binding vote in all other votes.
> - can be removed by a super majority vote of the Lead Developers.
> - can have a removal vote vetoed by a super majority vote of the General
>   Developers.
> - are automatically nominated and seconded for a removal vote after one 
> year of
>   inactivity (defined as no committed changes to any part of the project's
>   source code or documentation repositories).
> 
> Lead Developers:
> - are elected from among the General Developers by a simple majority vote of
>   the General + Lead Developers.
> - have commit access to the various project components, at the discretion of
>   the Lead over that component.
> - are required to cast a binding vote in all Lead Election and other votes.
> - serve an unlimited term as long as they are not removed by vote.
> - can be removed as Leads by a super majority vote of the other Lead
>   Developers.
> - can have a removal vote vetoed by a super majority vote of the General
>   Developers.
> - are automatically removed without vote or veto if they fail to cast any 
> votes
>   for two consecutive months or longer, provided there were at least two 
> votes
>   hold in that period.
> - are automatically nominated and seconded for a removal vote after six 
> months
>   of inactivity (defined as no committed changes to any part of the 
> project's
>   source code or documentation repositories).
> - revert to General Developers if removed.
> 
> Project and Component Leads:
> - are elected from among the Lead Developers by a simple majority vote of 
> the
>   General + Lead Developers.
> - remain Lead Developers.
> - have primary responsibilty for and daily authority over one of the 
> identified
>   Project Components (or in the case of the Project Lead, the entire 
> Project).
> - are subject to the outcome of any votes affecting their Components.
> - serve a one year term, with no limit on number of terms.
> - can be removed as Project or Component Leads by a super majority vote of 
> the
>   other Lead Developers.
> - can have a removal vote vetoed by a super majority vote of the General
>   Developers.
> - remain Lead Developers if removed.
> 
> Assistants:
> - can be any General or Lead Developer chosen by the individual Project and
>   Component Leads.
> - act on behalf of and with the authority of the Lead they are assisting, at
>   the Lead's discretion.
> - do not receive any extra binding or non-binding vote as an Assistant.
> - can cast the Lead's binding vote in their place in any vote, at the Lead's
>   discretion.
> - retain their own binding or non-binding individual vote for all elections
>   they would otherwise be involved in.
> - revert to their regular, non-assistant status if the Lead they are 
> assisting
>   steps down or is otherwise removed as Lead.
> 
> For more information on Lead elections see the Voting Policy.
> 
> 
> ------------------------------------------------------------------------
> 
> Note: Several aspects of the Voting Policy are inspired by voting formats 
> used
> by other F/OSS projects, most notably the Apache project.  If you are 
> unfamilar
> with terms like '(non-)binding votes' or expressing a vote as '+/-1' and
> '+/-0', please refer to http://www.apache.org/foundation/voting.html for 
> some
> general discussion, but keep in mind that only the usage explicitly 
> described
> in this policy is valid for Source Mage.
> 
> Voting Policy
> =============
> 
> General:
> - The Mailing List used for voting is sm-discuss AT lists.ibiblio.org.
> - A "Developer" in this policy is any General or Lead Developer, as defined
>   by the Developer Organization document, who was a Developer at the time 
> the
>   given vote began (the time the call for nominations was made or the time a
>   given motion was first proposed).
> - The terms "MAY", "SHOULD", "MUST", and "MUST NOT" when used in this Policy
>   have the meanings assigned them in RFC 2119.  The term "WILL" is used to
>   specify expectations for the voting process itself and the person(s)
>   administering it.  If a vote is not held in compliance with these "WILL"
>   specifications, any Developer MAY move that the current vote be 
> invalidated
>   and started over.  If the revote motion is seconded the current vote WILL 
> be
>   immediately suspended and the revote motion WILL proceed as an Issue Vote 
> as
>   described below.  If the revote motion carries (on initial vote or veto) 
> the
>   current vote WILL be started over by the relevant Lead or their 
> Assistant(s)
>   within one week of the scheduled end of the revote motion vote.
> - All nominations, motions, seconds, votes, etc. MUST be GPG-signed by the
>   Developer's GPG key as recorded at http://www.sourcemage.org/keysigning 
> to be
>   valid.
> 
> Lead Developer Votes:
> - A General Developer MAY be nominated for Lead Developer at any time by any
>   other Developer.
> - Nominations MUST be sent to the Mailing List.
> - The nomination MUST be seconded within one week of being made.
> - The nomination MUST be accepted within one week of being made.
> - If a nomination is seconded and accepted the Project Lead or their
>   assistant(s) WILL call for a vote within two weeks of the date the 
> nomination
>   was made.
> - Votes WILL proceed per the Lead Voting Process described below.
> 
> Project and Component Lead Votes:
> - Component Lead Votes WILL occur during specific months, as follows:
>   - January:   Project Lead
>   - March:     Grimoire Lead
>   - May:       Cauldron Lead
>   - July:      Sorcery Lead
>   - September: Tome Lead
> - The Project Lead WILL send a call for nominations to the Mailing List the
>   first week of the relevant month.
> - Nominations WILL last for one week from the time the call for nominations 
> is
>   sent.
> - Nominations MUST be sent to the Mailing List.
> - The nomination MUST be seconded within one week of being made.
> - The nomination MUST be accepted within one week of being made.
> - Accepting nominees SHOULD send a message to the list explaining why they 
> are
>   running for the position and why people might want to elect them.
> - Two weeks after calling for nominations, the Project Lead or their
>   Assistant(s) WILL call for a vote.
> - Votes WILL proceed per the Lead Voting Process described below.
> - If there are no nominees or the incumbent Lead is the only accepting 
> nominee
>   they are reelected without a vote.
> - The Lead's term begins the first day of the month following their election
>   and lasts for one year.
> - If a Project or Component Lead is removed or steps down before the end of
>   their regular term, the Project Lead (or, in the case of the Project Lead
>   being the one removed, any other Lead Developer) WILL call for nominations
>   for a replacement within one week of the effective date of the Lead's
>   removal.  The voting process for the replacement WILL continue as 
> described
>   above.  The replacement WILL at most serve out the remainder of the 
> existing
>   term for that position, and the regular vote WILL be held when scheduled.
> - If at any time a Project or Component Lead position is empty (due to lack 
> of
>   available candidates, etc.), the Project Lead (or any Lead Developer, in 
> the
>   case of a Project Lead vacancy) MAY schedule a new vote for a temporary 
> Lead
>   to fill the position until the next scheduled election.  The vote will
>   continue as described above.
> 
> Lead Voting Process:
> - Lead votes last one week from the date they are called for.
> - Votes MUST be sent via private email to the Project Lead or the Assistant 
> who
>   called the vote as an ordered list of the candidates or "abstain".
> - Votes MUST be received at the designated email address by the scheduled 
> end
>   of the vote to be valid.
> - Lead Developers MUST cast a vote.
> - General Developers MAY cast a vote.
> - 51% of the Lead Developers MUST cast a vote, or the vote is invalid.
> - Votes require a simple (51%) majority to pass.
> - If no quorom or majority is achieved, and the vote is for a Project or
>   Component lead, and the incumbent is a valid candidate, they are 
> reelected.
>   If there is no incumbent or they have not accepted a nomination, the 
> position
>   becomes vacant.
> - Within 48 hours of the receipt of a vote the vote counter WILL respond to 
> the
>   voter via private email with an acknowledgement of the vote and an 
> anonymized
>   receipt string.
> - Within 72 hours of the end of the vote the vote counter WILL post the 
> results
>   to the Mailing List as a list of all anonymized receipt strings and the 
> vote
>   they represent.
> - Any voter MAY contest the results within 72 hours of their posting.
> - If contested, the vote counter WILL produce the full votes with their
>   signatures and receipt strings to three other Lead Developers within 48
>   hours of the contest reaching the Mailing List.
> - These three Leads WILL provide their own list of receipt strings and their
>   respective votes to the Mailing List within 72 hours of receiving the 
> votes.
> - If the results are still contested, the vote counter WILL provide all 
> votes
>   and their signatures and receipt strings to the Mailing List within 48 
> hours
>   of the (second) contest.
> 
> Issue Voting Process:
> - While we prefer to operate based on general consensus, votes are at times
>   necessary to moves issues to resolution.  Therefore, any General or Lead
>   Developer MAY move for any issue to be put to a vote.
> - Motions for votes MUST be seconded within one week of being made.
> - If the motion is seconded the Project Lead or their Assistant(s) WILL call
>   for a vote within one week of the initial motion.
> - Votes last one week from the date they are called for.
> - Votes MUST be sent to the Mailing List as +1 (yes), -1 (no), +/-0 
> (abstain)
>   or an unambiguous equivalent.  "Unambiguous" is defined at the sole
>   discretion of the Project Lead.
> - Lead Developers MUST cast a vote.
> - General Developers MAY cast a vote, but their votes are advisory only 
> (i.e.,
>   non-binding).
> - 51% of the Lead Developers MUST cast a vote, or the vote is invalid and
>   fails.
> - Votes require a simple (51%) majority (of all binding votes cast) to pass.
> - Motions which pass are considered active immediately upon the majority 
> vote
>   reaching the Mailing List.
> 
> Developer Removal Voting Process:
> - General and Lead Developer Removal Votes WILL proceed per the Issue Voting
>   Process described above, with the following exceptions:
>   - The Developer in question MUST NOT vote.
>   - Removal Votes require a super (67%) majority to pass.
> - Successful or failed removal votes MAY be vetoed by the General 
> Developers.
> 
> General Developer Veto Process:
> - The General Developers MAY veto any Developer Removal Votes and any Issue
>   Votes which would modify the Project's organizational structure or Voting
>   Policy.
> - Motions to veto MUST reach the Mailing List within 72 hours of the 
> scheduled
>   end of the vote in question.
> - Veto votes WILL proceed per the Issue Voting Process described above, with
>   the following exceptions:
>   - For Removal Votes, the Developer in question MUST NOT vote.
>   - Lead Developers MUST NOT vote.
>   - General Developers MAY cast a binding vote.
>   - 51% of the General Developers MUST cast a vote, or the veto is invalid 
> and
>     fails.
>   - Vetos require a super (67%) majority to pass.
> - Veto votes are final.

Thanks Jeremy. ;) While the above is long, I believe it covers our
issues and allows for people to work with SMGL as they want (just code
and ignore the politics or become 'more involved') while keeping as much
of our current setup as possible.

Are there any more comments/suggestions/questions about the above?

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFESnvlHXt9dKjv3WERAuCFAKCPLRZk+sCNERi9juXxgf7ZnFJ9wQCgl0yi
AL19f/EywkAZxa5IrP2s11A=
=7NXN
-----END PGP SIGNATURE-----