Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years...

[NP-Hardass]

On 10/06/2016 03:14 AM, Raymond Jennings wrote:
> Yes, Gentoo is kinda democratic because the projects elect their own leads.
>
> Questions:
>
> 1.  How to handle superprojects that are themselves composed of
> subprojects and may or may not have their own non-project members?
> Should the subprojects get to vote?  If so, do we just count the votes
> of each project's lead (probably elected bottom up), or all the
> project's members?
>
> 2.  If a project gets stagnant and "implodes into a ball of stiff stale
> tar" through complacency, should the gentoo developer community as a
> whole have veto power to be able to oust the lead?
>
> I'm kinda in favor of 2, just for the sake of keeping project leads
> accountable for making sure that the project exists to benefit gentoo as
> a whole.  And it would work for any project that goes off course from
> the needs of the whole community...and not just "hot button" projects
> like comrel or whatever.
>
> IIRC we already have leads elected by the members of the project to have
> accountability to the project and the needs of its membres, but what
> about the accountability of the project to the gentoo community as a whole?
>
> Bosses and leads provide organization and structure and a clear path of
> responsibility.
>
> As for 1, I think that making a project part of another
> project...hmm...who decides that?
>
> On Wed, Oct 5, 2016 at 9:55 AM, Gregory Woodbury <redwolfe@×××××.com>
> wrote:
>> On Mon, Oct 3, 2016 at 6:16 PM, Raymond Jennings <shentino@×××××.com>
>> wrote:
>>>
>>> The only comment I have right now...
>>>
>>> What if project leads were generally left in charge to run their
>>> projects as they see fit, but the gentoo developer community as a
>>> whole reserved the right to recall the lead if they don't like how
>>> the project is being managed?
>>>
>>> This would help with stagnant projects or the like or projects (such
>>> as the recent fight between games and council) that aren't responsive
>>> to the needs of the gentoo community.
>>>
>>> I like democracy, but who should the voters be?
>>>
>>
>> Well, that is, to me, a large part of the problem.
>>
>> The social/political structure of Gentoo is based on a status of
>> being an "accredited developer."  Meaning that there are hoops to jump
>> through to prove that one has a sufficiently advanced technical
>> ability, and an ability to work within the rules.  This restriction on
>> who gets a vote or not makes the situation into one of conservative
>> vs. progressive: restricted voting rights are associated with corporate
>> cultures that are inherently conservative. They are often more concerned
>> with maintaining a "status quo" than in moving forward.
>>
>> This is *exactly* what and why these conversations are taking place
>> here and now.
>>
>>
>> --
>> G.Wolfe Woodbury
>> redwolfe@×××××.com
>
>

We are bordering on ridiculous levels of destructive bureaucracy with
these suggestions.  Firstly, as it has been said before, you really
can't force volunteers to do anything... Secondly, kicking project
members externally is tantamount to forcing developers to do things.
What are you going to do when there is one project member and you think
they are slacking?  Kick them, and end up with no one working instead of
someone working at reduced speed?  Thirdly, project leadership is a
democratic process for the project members; they can vote on who to lead
them.  Does it make sense for an unrelated third party to determine
this?   No.  If I am working with a group of developers, it makes no
sense for someone unrelated to start telling us how we can best operate.
 If we disagree, we don't do it, and that puts us back with #2.  You
start trying to force people to do things, and you end up with nothing.
Fourth, a developer may call for a new election of a lead at any time.
If a project truly feels that their lead is not doing their job, they
can call for a vote to change that.  Fifth, if a developer feels that a
project (that they are not a part of) is not working they way they'd
like, with the exception of a few projects, there is little to no
barrier to that developer joining and making whatever impact that they
want to.

Moreover, I think you are overestimating the power of the role of lead.
In some projects, it might mean that the person makes a lot of
decisions, in others, it might mean that the person merely guides
things.  As GLEP 39 states, it isn't up to the GLEP to impose leadership
or what that leader does, it is up to the project and what the project
thinks is best.  Council has ruled on this previously.  The GLEP is
ambiguous and their verdict was "Do what works best for you."  You don't
even have to have a lead if you feel that some other structure would
work better within your project.  Right now, project leadership is less
of a bureaucratic role, and more of a functional/technical role.  There
are benefits to adding some mandatory responsibilities, but you don't
want it to become overbearing.   What are we going to do if my Project
MATE which has only me as a project member and lead and I am slacking?
Can you truly force me to do something?  The only real punishment you
can give me is to kick me, and what does that do?  It makes all MATE
users suffer because they now have 0 developers instead of 1.  The real
way that you affect change is by getting involved in a project, not
yelling from the sidelines (eg external parties telling a project how to
operate).  But let's go back to the concept of "ousting the lead..." The
implication is that the lead is the sole reason why a project is not
doing what some external party thinks it should be doing.  Unless the
lead is a malevolent dictator, the responsibility is shared by all of
the project members.  Just chucking out the lead really won't do
anything.  And if the lead truly is a malevolent dictator who is holding
the project back, the project members can, if they feel that someone
else would do a better job, hold an election to replace the lead.

TL;DR: Projects already are designed to handle leadership internally.
This is best handled by those involved.  Those that aren't involved are
welcome to get involved if they think they can make an impact.  You
can't force anyone to do anything, and attempting to do so is often and
likely detrimental.

-- 
NP-Hardass