--- HACKING.md | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+)
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} ================ -- 2.7.4 _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev