[quagga-dev,16527,2/3] HACKING: Add 'Objectives', 'Governance', and an initial 'Code of Conduct'

Message ID 1484231064-7420-2-git-send-email-paul@jakma.org
State Under Review
Headers show
Series
  • [quagga-dev,16526,1/3] HACKING: set a4paper by default
Related show

Commit Message

Paul Jakma Jan. 12, 2017, 2:24 p.m.
---
 HACKING.md | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 110 insertions(+)

Comments

Paul Jakma Feb. 2, 2017, 1:08 p.m. | #1
On Thu, 12 Jan 2017, Paul Jakma wrote:

> +Governance {#sec:governance}
> +==========
> +
> +The governance of Quagga is currently in flux.
> +
> +Quagga was forked from GNU Zebra by Paul Jakma, who holds the domain name.
> +Governance was soon devolved to a collective group, the maintainers.
> +
> +Governance at this moment is again fully in the hands of Paul Jakma, to be
> +recast.
> +
> +Holding of project assets
> +-------------------------
> +
> +One or more mature, independent trustees, with technical and free software
> +experience, will be appointed as the executor(s) for key assets of the
> +project to ensure continuity, such as the domain name.
> +
> +Should a corporate vehicle ever be created to hold such assets it __must__:
> +
> +* Publish up to date accounts on a regular business.
> +* Generally operate openly and transparently.
> +* Have control distributed, with a significant degree of control held
> +  independent of any contributors with business interests in the software.
> +* Carry out no other business itself that may be seen to conflict or compete
> +  with the business of others in the community.
> +* Have all officers disclose all interests that could be
> +  seen to have a bearing on the project, as far as is reasonable.
> +
> +It not clear at this time that the overheads and potential liabilities of
> +such a vehicle would be appropriate for this project.  These principles
> +should though still be applied, where possible, to any non-corporate body
> +formed around the project.

Oh, others in the past (before the lovely manoeuvrings of '15/'16) have 
made a good case for SFConservancy.org. Though:

a) It doesn't avoid having to sort out project side governance, to
    interface with SFConservancy.

b) One other issue I had was that any long-term assets (e.g. domain
    names) would end up stuck under US law pretty much forever more. I
    would probably prefer a more local jurisdiction.

I read recently of a UK CIC (a type of UK corporate body required to act 
in the public-interest) with similar aims to SFConservancy:

 	https://publicsoftware.eu/

(via:
   https://lwn.net/SubscriberLink/713073/fd6db0a111ab8b7e/
   / https://lwn.net/Articles/713073/ )

Maybe an option. Assuming a community rebuilds again anyway...

regards,

Patch hide | download patch | download mbox

diff --git a/HACKING.md b/HACKING.md
index c898d96..0b96ce8 100644
--- a/HACKING.md
+++ b/HACKING.md
@@ -17,6 +17,116 @@  include-before:
 
 \newpage
 
+OBJECTIVES {#sec:goals}
+==========
+
+The objectives of the Quagga project are to develop and implement high
+quality routing protocols and related software, maximising:
+
+* Free software:
+    * Quagga is and will remain a copyleft, free software project
+    * Some non-core parts may be available under compatible, permissive
+      licenses to facilitate code sharing, where contributors agree.
+    * The test and integration orchestration infrastructure shall be free
+      software, developed similarly to the rest of Quagga. Proprietary
+      conformance suites may be among the test tools orchestrated.
+* Openness and transparency
+    * The business of the project shall be conducted on its public email
+      lists, to the greatest extent possible.
+    * The design of the software will be governed by open discussion on
+      the public email lists.
+    * Participants shall endeavour to be transparent about their interests
+      in the project, and any associations likely to be relevant.
+* Ethical behaviour:
+    * The licenses of all copyright holders will be respected, and the
+      project will err in their favour where there is reasonable doubt or
+      legal advice to that effect.
+    * Participants will behave with respect for others, and in a manner that
+      builds and maintains the trust needed for productive collaboration.
+
+See also the Section on [CODE OF CONDUCT](#sec:codeconduct).
+
+Governance {#sec:governance}
+==========
+
+The governance of Quagga is currently in flux.
+
+Quagga was forked from GNU Zebra by Paul Jakma, who holds the domain name. 
+Governance was soon devolved to a collective group, the maintainers. 
+
+Governance at this moment is again fully in the hands of Paul Jakma, to be
+recast.
+
+Holding of project assets
+-------------------------
+
+One or more mature, independent trustees, with technical and free software
+experience, will be appointed as the executor(s) for key assets of the
+project to ensure continuity, such as the domain name.
+
+Should a corporate vehicle ever be created to hold such assets it __must__:
+
+* Publish up to date accounts on a regular business.
+* Generally operate openly and transparently.
+* Have control distributed, with a significant degree of control held
+  independent of any contributors with business interests in the software.
+* Carry out no other business itself that may be seen to conflict or compete
+  with the business of others in the community.
+* Have all officers disclose all interests that could be
+  seen to have a bearing on the project, as far as is reasonable.
+
+It not clear at this time that the overheads and potential liabilities of
+such a vehicle would be appropriate for this project.  These principles
+should though still be applied, where possible, to any non-corporate body
+formed around the project.
+
+CODE OF CONDUCT {#sec:codeconduct}
+===============
+
+Participants will treat each other with respect and integrity.  Participants
+will build and treasure the trust that is required for parties to
+successfully collaborate together on free software.  Particularly when those
+parties may have competing interests.  The following principles and
+guidelines should be followed to foster that trust:
+
+* Participants should be open about their goals, and their interests.
+    - Business associations with other participants should be disclosed,
+      so far as is reasonable and where applicable. E.g., if there is voting
+      on matters, or in endorsements or objections to contributions.
+    - Other associations and interests that may be relevant should be
+      disclosed, to the degree necessary to avoid any perception
+      by others of conflicts of interests or of deception.
+    - Be open about your goals, so as to maximise the common understanding
+      and minimise any misunderstandings and disputes.
+* Design should be done in the open
+    -  Do your design on list, ahead of significant implementation.  Avoid
+      "Surprise!" development where possible.
+    - Where significant implementation work must be done behind closed
+      doors, accept that you may be asked to rework it, potentially from
+      scratch once you take it public.
+    - Get "buy in" from others ahead of time, to avoid disappointment.
+* Interaction 
+    - Feedback on design should be constructive, thoughtful and 
+      understanding.
+    - Avoid personalising matters. Discuss the idea, the code, the abstract
+      subject and avoid unnecessary personal pronouns.
+    - Avoid language that paints either party into a corner. Leave some room
+      for doubt. Ask questions, rather than make assertions, where possible.
+* Disputes should be resolved through calm, analytic discussion
+    - Separate out as much of the matter under dispute into principles that
+      can be agreed on, and into the objective domain (by measurement or
+      logic). 
+    - Seek ways to resolve any remaining subjective differences by alternate
+      paths that can accommodate both sides, e.g., through abstraction or
+      modularisation.
+    - Aim for Win-Win.
+* Respect others
+    - Avoid passive-aggressive behaviours. E.g., tit-for-tat
+      non-constructive behaviour. Be explicit.
+    - It is acceptable for management to allocate resources on development
+      according to their need.  It is not acceptable to try use external,
+      management intervention to over-turn positions held by participants.
+
 REQUIRED READING {#sec:required}
 ================