PROPOSAL: Governance and sustainability

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

PROPOSAL: Governance and sustainability

Matt S Trout-2
The updated bootstrap governance document appears below - basically I've
attempted to tweak it so that, while business as usual can occur without
needing the list to expend time getting involved, the community now gets
a clear veto - and there's a forcible recall method (forced vote) to defend
against the possibility of a rogue core team. I hope that said addition is
never required, but strongly believe there should be some final means of
redress in such a scenario.

Also, I'm encoding frew holding first-come, since I hold SQL::Abstract,
castaway SQL::Translator, and ilmari DBIx::Class::Schema::Loader, so it
seems like a sensible place to leave them.

I also want to give a rough idea of what I'm expecting to actually happen:

- The first days will be pure bugfixing while we get a handle on the codebase
- I don't intend to do a CPAN release at all without an RC release first to
  begin with, because (1) let's be careful (2) that means people can use the
  RC if they desperately need a bugfix sooner than the release vote will be
  completed
- I, personally, currently have no specific significant changes to propose,
  though that doesn't mean other people can't do so
- Once we do have a solid handle on the codebase, I expect any potential
  feature additions to be discussed before we start work, in order to ensure
  that the risk/reward trade-offs have been thoroughly covered
- I intend to prioritise letting people who want a specific feature work on
  it themselves, providing code review and design assistance, over doing so
  myself, so that we end up with a long-term viable team again
- There is absolutely increased short-term risk to doing it that way, but I
  believe that we need both stability and sustainability, since neither a
  broken nor a dead project is desirable in a core dependency
- If you don't think we've been sufficiently careful in that regard, you
  have the ability to veto both merges and releases. I've tried to bake
  "if in doubt, make the conservative choice" into the system itself
  intentionally, and would much rather have a rebellion before than after
  a release is shipped to CPAN.

With all that given, here's the updated governance document:

=begin GOVERNANCE

DBIx::Class Core Team and Voting System

Non normative section:

DBIx::Class originally operated under a BDFL system, but one where it was
expected that an informal core team would be maintained, and that where
consensus could not be pre-assumed, the core team and/or the user base
would be consulted publically such that measured decisions could be made.

This document is intended to formalise a form of this system, while still
providing room for the system to adapt later as required.

It is intended that this system provides confidence to the user base that
decisions will be made in the open and that their wishes will be taken into
account.

It is also intended that this system allows business as usual to happen
without unnecessary red tape.

It is not intended that this system becomes the primary decision making
process in and of itself; instead, it is intended that this system is used
to ratify consensus as formed by discussion, and only sparingly as a tie
breaking system when consensus cannot be reached.

Normative section:

Terms: VM - Voting Member - part of the benevolent dictatorship
       LS - List Subscriber - a subscriber to the mailing list
       LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes

Voting Members are:

  Matt S Trout (mst) cpan:MSTROUT
  Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
  Frew Schmidt (frew) cpan:FREW
  Jess Robinson (castaway) cpan:JROBINSON

PAUSE release perms are to be held by:

  Matt S Trout (mst) cpan:MSTROUT
  Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
  Frew Schmidt (frew) cpan:FREW
  Jess Robinson (castaway) cpan:JROBINSON

First come permissions are to be held by FREW.

(the above two lists may or may not be identical at any given time)

A resolution must be proposed and then successfully voted upon to:

  - Make a PAUSE-indexed (i.e. non-dev) release of DBIx::Class
  - Make changes to the master and blead branches of the repository
  - Amend this document

This document is currently in bootstrap phase, and as such no merges will be
made to master or blead until this sentence is removed.

A resolution that amends the 'PAUSE release perms' list is to be assumed to
also intend the permission within PAUSE itself to be updated accordingly.

Adding or removing entries from the list of situations requiring resolutions
is absolutely a valid topic for resolutions.

A resolution may be proposed for reasons including, but not limited to:

  - Force/revert/block a branch merge
  - Add/remove a commit bit
  - Resolve a design discussion
  - Anything you like, under the assumption frivolous proposals will be
    voted down naturally anyway

Merges to topic branches and similar actions that do not have a resolution
attached may be made at the discretion of those with ability to do so, but
a developer unsure if the merge will be uncontroversial is expected to ping
the list first so a vote can be called if people believe it to be required.

Rules that restrict this "ask unless you're sure" trust-by-default position
are also absolutely a valid topic for resolutions.

Resolution proposal:

A resolution is proposed by starting a new thread entitled 'PROPOSAL: ...'

A resolution must be seconded before it is voted upon.

If a VM makes or seconds a proposal, they are required to abstain from
voting upon it.

If a non-VM LS makes or seconds a proposal, no such restriction applies.

Resolution voting:

Once a proposal is seconded, the initial proposer may start a new thread
entitled 'VOTE: ...' (voting does not automatically begin after seconding
in case other feedback leads the proposer to wish to alter and re-present
their proposal).

Each VM may cast one vote, either +1, -1 or abstain.

Each non-VM LS may post +1 or -1, and the aggregate of those form the LAV.

Voting closes after 72h from when the proposal was first posted.

A resolution passes if the VM total is at least +1 and the LAV is
non-negative, to avoid requiring the list members to expend time to vote on
business as usual while still providing them a veto.

Resolution forcing:

If a resolution gains a positive LAV, but is voted down by the VMs, a force
vote may be proposed. This requires two list members who did not propose or
second the initial resolution to propose and second the force vote.

A force vote also lasts 72h, and is LAV-only. If it receives at least 25%
more +1s than -1s, the resolution passes no matter the VM vote.

This mechanism is not intended to be needed on a regular basis, but exists
to permit the list to forcibly recall a VM if they believe it to be necessary.

Once a resolution has passed, the resolution will be carried out by those with
the power to do so.  It will not be reverted without a new resolution
amending or reversing the decision of the previous once.

Passed resolutions will be recorded in a RESOLUTIONS file maintained next
to this document.

=end GOVERNANCE

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Matt S Trout-2
I'm an idiot.

> Voting closes after 72h from when the proposal was first posted.

This line should be replaced with:

  Voting closes after 72h from when the VOTE: email is sent.

My apologies.

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Darren Duncan
Having read Matt's new proposal and its correction, it comes across as
reasonable and workable to me.  I have no thoughts at this time as to how it
could be improved.  This message is just feedback, and does not make any
relative value judgements between Matt's proposal and Peter's upcoming one. --
Darren Duncan

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Andrew Beverley
In reply to this post by Matt S Trout-2
Thanks for the updated governance MST. Just one comment/question from
me (this is not intended to be critical because I made the previous
alternate proposal, it's a genuine concern that I would like to see
answered that led me to make the previous alternative proposal):

> Voting Members are:
>
>   Matt S Trout (mst) cpan:MSTROUT
>   Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
>   Frew Schmidt (frew) cpan:FREW
>   Jess Robinson (castaway) cpan:JROBINSON

I'd like to hear some commitment from the above list that they have the
time and capacity (and to some extent experience) to comprehensively
review relevant changes. My concern is that relatively significant
changes could be proposed (and implemented), and not get the scrutiny
that they should have. If proposals get no votes (or "yeah looks okay
to me" type votes), then that's actually worse than a BDFL-type
approach, as the implementer gets a false sense of security that their
work is being reviewed, when they might otherwise have been more
careful.

I realise that there is the list vote as well, but my comments above
still stand in that regard (especially re experience - I would have no
idea whether proposed changes affect stability).

What I'm really trying to say is that we've all seen situations where
programmers (including me) have been more lax than they should have
been, when they think they have some sort of other security checking
their changes (be it peer-reviews, test suites, whatever).

Andy

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Alexander Hartmaier
In reply to this post by Matt S Trout-2
Are 72 hours enough to reach a significant amount of list members?
For releasing a CPAN version that's fine for me as git master should
always be in a releaseable state but for feature branch merges I'd like
to have this extended to  say a week.

What do the others think?


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Matt S Trout-2
On Tue, Nov 08, 2016 at 12:18:14PM +0100, Hartmaier Alexander wrote:
> Are 72 hours enough to reach a significant amount of list members?
> For releasing a CPAN version that's fine for me as git master should
> always be in a releaseable state but for feature branch merges I'd like
> to have this extended to  say a week.

I don't see a problem with this, but given the bootstrap line means we can't
initially merge anything, I was hoping such a tweak could be discussed as a
proposal itself because (a) if we don't take the governance route, it's a
waste of energy (ii) I'd really like to validate the proposal system by
using it to amend itself (3) the "can't touch master or blead until the
document is moved out of bootstrap by a vote" means that nobody can sneak
anything in before you get a chance to do that.

On the other hand, if people do want to discuss it and there seems to be
a decent number of people in favour, I don't mind amending the proposal
pre-voting - after all, if it turns out to be wrong somebody can put forward
a proposal to unamend it post-adoption instead :)

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Darren Duncan
On 2016-11-08 1:10 PM, Matt S Trout wrote:

> On Tue, Nov 08, 2016 at 12:18:14PM +0100, Hartmaier Alexander wrote:
>> Are 72 hours enough to reach a significant amount of list members?
>> For releasing a CPAN version that's fine for me as git master should
>> always be in a releaseable state but for feature branch merges I'd like
>> to have this extended to  say a week.
>
> I don't see a problem with this, but given the bootstrap line means we can't
> initially merge anything, I was hoping such a tweak could be discussed as a
> proposal itself because (a) if we don't take the governance route, it's a
> waste of energy (ii) I'd really like to validate the proposal system by
> using it to amend itself (3) the "can't touch master or blead until the
> document is moved out of bootstrap by a vote" means that nobody can sneak
> anything in before you get a chance to do that.
>
> On the other hand, if people do want to discuss it and there seems to be
> a decent number of people in favour, I don't mind amending the proposal
> pre-voting - after all, if it turns out to be wrong somebody can put forward
> a proposal to unamend it post-adoption instead :)

While on one hand 72 hours seems like plenty of time, in practice a week can be
better for the reasons of that 72 hours can more likely correspond to a weekend
or otherwise a common length of time that people may be away from the forum for
whatever reason, and so 72 hours could make it easy for people to miss out.  So
1 week is then also neutral to what day of the week that a vote is called as far
as how it affects or is affected by people's schedules, assuming say 99% of
people are oriented around 7-day cycles. -- Darren Duncan


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Governance and sustainability

Matt S Trout-2
In reply to this post by Andrew Beverley
On Tue, Nov 08, 2016 at 07:06:10AM +0000, Andrew Beverley wrote:
> Thanks for the updated governance MST. Just one comment/question from
> me (this is not intended to be critical because I made the previous
> alternate proposal, it's a genuine concern that I would like to see
> answered that led me to make the previous alternative proposal):

There's a reason why the opposition in parliament is called "Her Majesty's
Loyal Opposition" and so far all of your disagreement with and questioning
of my ideas has absolutely seemed to me to be in that spirit (rather more
so than our actual politicians manage, of course).
 

> > Voting Members are:
> >
> >   Matt S Trout (mst) cpan:MSTROUT
> >   Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
> >   Frew Schmidt (frew) cpan:FREW
> >   Jess Robinson (castaway) cpan:JROBINSON
>
> I'd like to hear some commitment from the above list that they have the
> time and capacity (and to some extent experience) to comprehensively
> review relevant changes. My concern is that relatively significant
> changes could be proposed (and implemented), and not get the scrutiny
> that they should have. If proposals get no votes (or "yeah looks okay
> to me" type votes), then that's actually worse than a BDFL-type
> approach, as the implementer gets a false sense of security that their
> work is being reviewed, when they might otherwise have been more
> careful.
>
> I realise that there is the list vote as well, but my comments above
> still stand in that regard (especially re experience - I would have no
> idea whether proposed changes affect stability).
>
> What I'm really trying to say is that we've all seen situations where
> programmers (including me) have been more lax than they should have
> been, when they think they have some sort of other security checking
> their changes (be it peer-reviews, test suites, whatever).

So, I think we all have at least some familiarity with the codebase. We're
not perfect, but basically we're the best available, and pretty much the
best people-not-riba (and given he's re-iterated more than once that he's
going to provide a guide to the codebase, that should rather help). More
importantly, I think we all have the sense to say "looks ok to me, but I'm
not sure", at which point somebody else should take a look and we should
probably make a note to ship a dev release with the patch in and make people
test it *before* it gets merged anywhere (dev releases are cheap :).

I see what you mean about the "was this review thorough" question, though;
I would I think argue that it's expected that whoever makes the PROPOSAL for
a merge should have done a thorough review of the code - or at least have
the assurances of somebody who has.

Since the proposals are going to be recorded, I think that, basically,
your reasons why you believe that merging something is (a) going to do
something useful (b) not going to break anything should be included in the
proposal, so that the reasoning is greppable later if we need it.

Which means that while the list vote can't necessarily tell if we've checked
carefully enough, they can at least tell if the analysis for (b) seems half
arsed and tell us to try harder. And writing up those analyses for the future
record seems a useful thing to do to me *anyway*, and I figure over time
we'll settle on a reasonable set of trade-offs over 'effort required to
merge something' versus 'how well we trust our merges'.

What seems to regularly get lost in this conversation is that, well, my
views on "how much conservatism is enough" are still a long way towards
the conservative end of the spectrum; there've been quite a few #toolchain
arguments over the years that were basically "mst and riba versus everybody
else". But beyond pointing that out, I'm not sure how I prove that we're
going to take this seriously except for to get the chance to take it
seriously and successfully get it right.

I'd be perfectly happy to formalise merge proposals as requiring sections
X, Y and Z to be written out - or we can do it informally for the first few,
with the LAV voting us down if we underdo it, and then commit something into
the governance doc once the system's baked.

Apologies for the slightly waffly response, but I'm trying to tease out the
various aspects, while suffering from the problem, roughly, of "I already
believe in us as, at least, the best people to try, so I'm unsure what
assurances would work" while at the same time wanting a process that actually
works as well as looking comforting.

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...