On Mon, Sep 22, 2014 at 5:38 PM, Johannes Schlüter <johan...@schlueters.de> wrote:
> Slightly provocative: Why should I be forced to maintain code by people who > don't want to maintain it themselves? Probably even due to votes by people > about whom I don't know anything? Mind that most maintenance work by > most contributors happens in free time on a voluntarily base. The same applies to many new codes. Even more for my team as we have to take care of many issues where only a few actually takes care of. > And no open source doesn't mean democracy as governing model. The > democratic part is that people who don't like it can fork the project and > eventually receive a higher traction. But no, "one man one vote" and full > equality doesn't work out. (i.e. if a modules primary maintainer vetos a > change I have to mind that [which doesn't mean I have to agree in the > end]) Primary maintainers doing only maintenance but not having actually designed/implemented an extension fits in this description. That sounds pretty awkward to me, for anything landing in the core. Landed in the core? Dictartorship goes away. >>Using separated voting count isn't an option? Like only internal >>changes >>are voted only by people with karma and features/changes/small BC >>breaks >>that affects userland are allowed to anyone. This way I believe is easy >>to >>say if either internals and community agrees with the proposed change >>and >>community people are making their opinion count. > > There are no plans (and enough people who'd veto such plans) to close > the mailing list. Everybody might state their opinion and we are happy to > receive (constructive) feedback and ideas here. And yes, this can be a bit > painful due to different forms of "trolling" but leads to better results > respecting > more opinions than a yes/no vote. Never worked before and it will suddenly work? I am open to know how one can make it works. Unless you mean to go back to individual deciding everything for a given area or ext. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
