[LEDE-DEV] openwrt and lede - remerge proposal

[Eric Luehrsen]

In my comments, recognize LEDE rules and consider them a great start. 
Also there seems to be a lot of chatter about concerns of merge 
compromise to these rules. Some of those concerns seem well founded.

I would suggest that the LEDE rules be edited with some more 
consideration to recently raised concerns. Then, all members OpenWrt and 
LEDE side vote to agree to adhere to the (new?) rules as written.

It can all be in the details. The following are examples of deeper 
thinking that could to go into the rules. The following are not the 
"answer" but rather the stream of consciousness that might arrive at the 
right "question."

For example, rule (7) says all votes and decisions will be public but it 
lacks a formal expression that some decisions (intermediate term) need 
confidentiality. How do you handle bidding for services or inquiries by 
sponsors? "Time Limited Confidentiality" is a necessity but uncovered by 
the rules it becomes what we call in process engineering "hidden 
factory." It erodes the value of the rule and evolves into an excuse to 
ignore the rule.

For example, rule (10) contentious email clause could be dealt with 
maybe if rule (12) had more details and more teeth. What if rule (12) 
put a higher order of behavioral expectations on voting members. Would 
that permit personally named email accounts with the project domain to 
be given for the purpose of representing the project in upstream 
commits? What if a new rule was added that all email between the project 
and outside individuals or organizations is cc: to an archive? This 
archive would be made public, only redacting unfinished business for 
short time as I mentioned for updates to rule (7). Would this calm 
people down?

On 05/12/2017 12:17 AM, David Lang wrote:
> thereare formal rules:
>
> https://lede-project.org/rules
>
> 1. The only role distinction within the LEDE project is between
> committers and non-committers, there is no core developer group or other
> specially privileged members.
>
> 2. All committers have the right to vote and are invited to liberally
> exercise this voting right in order to keep a broad consensus on project
> matters.
>
> 3. Project matters, overall development directions etc. are decided by
> simple majority votes. Votes may be held in different ways like simple
> yes/no decisions, majority decisions among multiple proposed choices etc.
>
> 4. Committers being unreachable for three months in a row shall get
> their commit and voting rights revoked in order to retain the ability to
> do majority votes among the remaining active committers.
>
> 5. There shall be only full commit rights in any case, no partial access
> or otherwise restricted access to the repositories.
>
> 6. Frequent contributors may become committers after a simple majority
> agreement among existing committers. Project members are free to suggest
> suitable people.
>
> 7. Any votes and decisions made will be made public on the project
> websites.
>
> 8. Project infrastructure should be outsourced FOSS community operated
> services whenever possible in order to allow project members to focus on
> actual development efforts.
>
> 9. Any infrastructure that cannot be outsourced and/or is operated by
> the project itself shall be administrable by at least three different
> people to reduce the likelyhood of the project getting locked out due to
> operators being unreachable.
>
> 10. Responsible operators for the various services shall be documented
> publicly. The project will not offer email accounts under its project
> domain for privacy and equality reasons.
>
> 11. Changes to these rules require a two third majority among the
> committers holding voting rights and shall be documented.
>
> 12. Be nice to each other.
>
> what is it on this list that people are objecting to?
>
> what is it that people say needs to be added to the list?
>
> are the people objecting amoung those who would have to comply with
> these rules? or are they outsiders (I am an outsider)
>
> David Lang
>
> On Fri, 12 May 2017, Eric Luehrsen wrote:
>
>> Date: Fri, 12 May 2017 04:09:31 +0000
>> From: Eric Luehrsen <ericluehrsen at hotmail.com>
>> Cc: LEDE Development List <lede-dev at lists.infradead.org>
>> Subject: Re: [LEDE-DEV] openwrt and lede - remerge proposal
>>
>> I read this on going thread and ... (sigh).
>>
>> "Good fences make good neighbors." Robert Frost
>>
>> People don't like rules and that could be even more true with open
>> source work groups. However, a good set of _limited_ rules can make life
>> easier. You may focus on important work or joyful recreation while not
>> worrying about accidental trespasses.
>>
>> I was trying to hold back a thought as formal as "bylaws" but perhaps
>> that is really the best way. That is ignore all the thoughts of what to
>> name the community, who would handle the accounts, and where to point
>> the DNS to. First thing and prerequisite to all others is a set of
>> governing principals for a yet unnamed community. This community is for
>> members who share a common affliction that they cannot help themselves
>> but hack on embedded networking software.
>>
>> This applies not only to the voting members, but to the interactions
>> respective to the wider community of contributers and power users. Much
>> of OpenWrt/LEDE progress, interest, relevance, and value is made by
>> these members of the wider community. The size of the sphere of
>> influence and the community's self worth are determined by issues such
>> as: on-boarding of voting members, on-boarding of committing members,
>> separating requirement of commits from votes, transparency of decision
>> making, email accounts, other privileges that over emphasize badge of
>> authority, and general attitude of the core voting members.
>>
>> Such schisms occur in all organizations (business and nations). When it
>> happens the first time, then it is a leaning opportunity. If the
>> opportunity is ignored, or the solution glosses over the details of the
>> underlying root cause, then the situation will repeat. A repeat event is
>> more damaging to the credibility of an organization than the first one.
>>
>> - Eric
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>