Re: [Dbix-class] Alternative proposals proposal

2016-10-17 Thread David Golden
On Mon, Oct 17, 2016 at 2:38 AM, Peter Rabbitson 
wrote:

> The dispute has *not* been resolved. The PAUSE admins simply pushed one of
> the disputing parties out.
>
>
Peter, your choice of words like "forfeit" and "not the right person to
captain this ship" and your request for PAUSE administrators to choose what
happens next and "push the button" and so on indicate that you acknowledge
you don't have the support you thought you did that would justify your
claim of moral authority to enact your plan.  Thus, through your own
actions – not that of PAUSE administrators – the dispute is resolved.

A resolution within the community – arrived at via discussion – is what the
PAUSE administrators felt would be the best way to resolve this dispute.
Because you initially refused to recognize the dispute, refused to discuss
your plans with your fellow maintainers or community, and seemed resolute
on acting in secret without consultation, we prohibited you from proceeding
in such a unilateral fashion so as to force discussion to occur.  We
believe the subsequent discussion and resolution within the community
rather than by external fiat is ample evidence of the wisdom of that
approach.

David


-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

2016-10-16 Thread Peter Rabbitson

On 10/17/2016 05:10 AM, David Golden wrote:



In the face of opposition to the minimal details of your plan, you
acknowledged that you didn't have the community support you thought and
"forfeited" (in your words) your claim.



This is a misrepresentation of the events that took place. The PAUSE 
admins articulated that they will not allow me to exercise my right of 
FIRSTCOME[1], which led to the following[2]:



* I strongly disagree with the PAUSE admins interpretation of my
ownership of this project, and I strongly believe a procedural
overstepping has taken place. However, the triggered discussion
indicates my leadership is not without controversy, and therefore as
indicated earlier[7], I am forfeiting my right to select the next FIRSTCOME.


As it was not immediately obvious that I am acting under duress, I wrote 
the following clarification[3]



I am really unhappy that me choosing to not fight for my rights is seen
as abdication, instead of being an attempt to prevent the project
suffering more damage than it already has.


Then you turn around and say:



...
(b) that PAUSE admins strip him of his authority

With the dispute resolved, (b) would be – in your words and the words of
others – unprecedented.


The dispute has *not* been resolved. The PAUSE admins simply pushed one 
of the disputing parties out.


Your suggestion that "we have never stripped an author of their 
authority" doesn't match your actions over the past couple weeks.


Have the integrity to own up to creating the very precedent you claim 
never happened.


Cheers

[1] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96181.html
[2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012265.html
[3] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012274.html

___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

2016-10-16 Thread David Golden
On Sun, Oct 16, 2016 at 3:04 AM, Peter Rabbitson 
wrote:

> It is the responsibility of the current interim project owners (the PAUSE
> admins) to institute this balanced state.
>
>
You seem determined to invent a narrative that suits your purpose or salves
your conscience.  We – the PAUSE admins – are not owners, nor obligated to
institute balance.

We are involved to mediate a dispute: your claim of moral authority versus
your prior agreement with Matt about a revocable transfer of primary
permissions.

We said that we felt that the maintainers – and more broadly the DBIC
community – are better informed to make this decision and hoped it could be
resolved within the community.

You suggested we take it to the community via the DBIC mailing list.  We
did.

In the face of opposition to the minimal details of your plan, you
acknowledged that you didn't have the community support you thought and
"forfeited" (in your words) your claim.

We continue to be involved for three reasons:

(a) because you feel it would be against your conscience to "push the
button" to carry out the eventual wishes of the community
(b) because we believe we should continue to encourage dialog to ensure all
voices are represented
(c) because we can be a conduit for voices that aren't able to speak openly
on the mailing list

However, the responsibility for a "balanced state" rests with the
maintainers and community, as it always has.  We can encourage voices to
assist in arriving at balance, but have no obligation nor responsibility to
make it happen.


> David, the fact that you equate "not giving a key" with "symbolic value"
> is deeply troubling to me, on both personal and administrative level. Your
> question essentially reads "but mst will still try to be involved, why not
> just let him play".
>
>
Given that the community did not support your plan to oust other
maintainers, freeze the project, and hand DBIC over to an unknown
caretaker, your claim of moral authority taking precedence over your prior
agreement with Matt does not hold up.

That means Matt is free – should he choose – to exercise his right to
resume primary permissions.  He hasn't (yet) done so – instead he has
suggested revitalizing group governance rather than continuing under his
sole governance.

You appear to be suggesting something else, either:

(a) that Matt voluntarily give up his authority

(b) that PAUSE admins strip him of his authority

With the dispute resolved, (b) would be – in your words and the words of
others – unprecedented.  The PAUSE administrators are not going to
interfere in the governance decisions of the DBIC community beyond
encouraging participation and "pushing the button" so you don't have to.

For (a) to be successful, you need to make a case either to Matt directly
or to the community to make a case to Matt for why his ceding authority is
in the best interests of the project.  This is why I – speaking personally
– suggested you elaborate.

I appreciate that you did articulate a mechanism: Your view that not having
Matt in the core increases the friction for new work being included in DBIC
itself rather in separate namespaces.  Having encouraged you to specifics,
I will leave assessment of the mechanism to the community.

Regards,
David

-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

2016-10-16 Thread Peter Rabbitson

On 10/14/2016 08:48 AM, David Golden wrote:


So, speaking personally, I understand clearly that you object to Matt
being part of a core team, but I'd like to understand the *mechanism* by
which you think that will change the evolution of DBIC.

Even if Matt were not on a core team, or even if he didn't have PAUSE
permissions, I don't think he would disappear from the project.  I think
he would – if he desired – continue to advocate for his points of view,
much as he does in many other parts of the Perl ecosystem where he
doesn't have administrative authority.

Therefore, I'd like to understand whether you think Matt not being on
the core team has merely symbolic power, or whether you think it has a
tangible effect and, if so, how you see that working in practice?



It is exactly *because* mst will continue advocating his amply 
documented "stable but just about" vision, and because of how 
(inconsistently) influential he is within the general public, some sort 
of balance tending towards the status quo needs to be introduced.


It is the responsibility of the current interim project owners (the 
PAUSE admins) to institute this balanced state.


On the question of mechanism: it would be logical that when *all* work 
*has* to go through a set of eyes predominantly *not* interested in 
exciting new stuff, the friction will increase the chances of said work 
happening where it belongs: in separate opt-in namespaces.


David, the fact that you equate "not giving a key" with "symbolic value" 
is deeply troubling to me, on both personal and administrative level. 
Your question essentially reads "but mst will still try to be involved, 
why not just let him play".


Imagine where we would have been with Test::Builder today if Exodist was 
just a chap with badly implemented ideas trying to push them to a wider 
audience.


If it is still unclear why Matt specifically: one has to start somewhere 
- why not with the disproportionally largest elephant in the room.


___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

2016-10-13 Thread David Golden
On Thu, Oct 13, 2016 at 4:42 PM, Peter Rabbitson 
wrote:

> It was suggested elsewhere I am against any "core team" plan. This is
> entirely false.
>

Hi, Peter.

Since in another thread you made it clear you interpret even my polite
requests as the demands of authority, let me stress that I have a couple
questions for you in my personal capacity, that I think would inform the
discussion and that you are free to ignore – though I hope you won't.  (And
in the future, please take that statement above as read if I preface my
remarks with 'speaking personally' or the like).

So, speaking personally, I understand clearly that you object to Matt being
part of a core team, but I'd like to understand the *mechanism* by which
you think that will change the evolution of DBIC.

Even if Matt were not on a core team, or even if he didn't have PAUSE
permissions, I don't think he would disappear from the project.  I think he
would – if he desired – continue to advocate for his points of view, much
as he does in many other parts of the Perl ecosystem where he doesn't have
administrative authority.

Therefore, I'd like to understand whether you think Matt not being on the
core team has merely symbolic power, or whether you think it has a tangible
effect and, if so, how you see that working in practice?

Personally, I don't see how it could have anything beyond symbolic value,
so given that you object to Matt's influence, I think it would be more
effective to identify and advocate for the elevation of contrasting points
of view for a "checks and balances" approach.  To that end, I appreciate
that – in proposing your own view of a possible core team you could support
– you've decided to identify some people you think could play a leadership
role.  Irrespective of whether they are interested, I think that's a
constructive step, so I thank you for being willing to do so.

Regards,
David

-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

2016-10-13 Thread Matt S Trout
On Thu, Oct 13, 2016 at 10:42:12PM +0200, Peter Rabbitson wrote:
> It was suggested elsewhere I am against any "core team" plan. This
> is entirely false.
> 
> As an *EXAMPLE* (I have not spoken to either of the poor saps
> below), a team similar to that would get several +1's from me:
> 
> https://metacpan.org/author/FREW
> https://metacpan.org/author/HAARG
> https://metacpan.org/author/ILMARI

HAARG said no. given our work together on Moo, I'd be happy to have him
replace me on any proposal I'm making, if you can talk him into saying yes.

-- 
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@lists.scsys.co.uk


Re: [Dbix-class] Alternative proposals proposal

2016-10-13 Thread Karen Etheridge
I don't see how more people would either "dilute responsibility" nor
destabilize the team.  For example, consider the people who hold comaint on
the Moose namespace:

https://metacpan.org/author/DOY
https://metacpan.org/author/DROLSKY
https://metacpan.org/author/ETHER
https://metacpan.org/author/FLORA
https://metacpan.org/author/GRODITI
https://metacpan.org/author/HDP
https://metacpan.org/author/MSTROUT
https://metacpan.org/author/PERIGRIN
https://metacpan.org/author/SARTAK
https://metacpan.org/author/STEVAN

or Catalyst:

https://metacpan.org/author/AGRUNDMA
https://metacpan.org/author/APEIRON
https://metacpan.org/author/ARCANEZ
https://metacpan.org/author/BOBTFISH
https://metacpan.org/author/BRICAS
https://metacpan.org/author/DGL
https://metacpan.org/author/EDENC
https://metacpan.org/author/ELLIOTT
https://metacpan.org/author/ETHER
https://metacpan.org/author/FLORA
https://metacpan.org/author/FREW
https://metacpan.org/author/HAARG
https://metacpan.org/author/ILMARI
https://metacpan.org/author/JJNAPIORK
https://metacpan.org/author/JROCKWAY
https://metacpan.org/author/MITHALDU
https://metacpan.org/author/MRAMBERG
https://metacpan.org/author/MSTROUT
https://metacpan.org/author/PHAYLON
https://metacpan.org/author/RIBASUSHI
https://metacpan.org/author/SSCAFFIDI
https://metacpan.org/author/VANSTYN
https://metacpan.org/author/WSHELDAHL

Both of these projects have some authors who contribute frequently, and some
less frequently, but in both cases it is reassuring to know that there are
additional people waiting in the wings to step in should a crisis occur
(either of the "she's off her meds" sort or "she was hit by a bus" sort).

Further, I would point out that Matt is comaint of both of these projects,
and
has **added to** the stability of them through his presence and advice, not
detracted from it.

Besides, Matt has held comaint on DBIx::Class itself all this time and has
not
meddled with the direction set by its BDFL for years; why would this be
expected to change if the leadership changed?  I am baffled at how such a
thing
would be presumed.




On Thu, Oct 13, 2016 at 1:42 PM, Peter Rabbitson 
wrote:

> It was suggested elsewhere I am against any "core team" plan. This is
> entirely false.
>
> As an *EXAMPLE* (I have not spoken to either of the poor saps below), a
> team similar to that would get several +1's from me:
>
> https://metacpan.org/author/FREW
> https://metacpan.org/author/HAARG
> https://metacpan.org/author/ILMARI
>
> If the number "5" is magical in some way, and diluting responsibility
> further is desirable: destabilize it a bit more, e.g.
>
> https://metacpan.org/author/FREW
> https://metacpan.org/author/HAARG
> https://metacpan.org/author/ILMARI
> https://metacpan.org/author/JROBINSON
> https://metacpan.org/author/SYSPETE
>
> As a community you seem to want prioritization of stability. Then why
> aren't you clamoring for a team that *mostly* leans towards stability
> *naturally*? I do not understand why settle for an illusion of a working
> group fully controlled by someone who demonstrably optimizes, and went on
> record intending to continue optimizing for progress for the sake of
> progress.
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

2016-10-13 Thread Matt S Trout
On Thu, Oct 13, 2016 at 10:42:12PM +0200, Peter Rabbitson wrote:
> As a community you seem to want prioritization of stability. Then
> why aren't you clamoring for a team that *mostly* leans towards
> stability *naturally*? I do not understand why settle for an
> illusion of a working group fully controlled by someone who
> demonstrably optimizes, and went on record intending to continue
> optimizing for progress for the sake of progress.

I disagree that I would "fully control" such a team, but it's clear that
you think less of our co-maints than I do.

Anybody who has genuine concerns that I would optimise for "progress for the
sake of progress" as opposed to the "impressive record of reliability" from
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/01.html is
very welcome to join the outstanding questions thread.

-- 
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@lists.scsys.co.uk


Re: [Dbix-class] Alternative proposals proposal

2016-10-13 Thread Darren Duncan
I support either of these team proposals, assuming the prospective members 
agree. -- Darren Duncan


On 2016-10-13 1:42 PM, Peter Rabbitson wrote:

It was suggested elsewhere I am against any "core team" plan. This is entirely
false.

As an *EXAMPLE* (I have not spoken to either of the poor saps below), a team
similar to that would get several +1's from me:

https://metacpan.org/author/FREW
https://metacpan.org/author/HAARG
https://metacpan.org/author/ILMARI

If the number "5" is magical in some way, and diluting responsibility further is
desirable: destabilize it a bit more, e.g.

https://metacpan.org/author/FREW
https://metacpan.org/author/HAARG
https://metacpan.org/author/ILMARI
https://metacpan.org/author/JROBINSON
https://metacpan.org/author/SYSPETE

As a community you seem to want prioritization of stability. Then why aren't you
clamoring for a team that *mostly* leans towards stability *naturally*? I do not
understand why settle for an illusion of a working group fully controlled by
someone who demonstrably optimizes, and went on record intending to continue
optimizing for progress for the sake of progress.



___
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@lists.scsys.co.uk