Integrated more content and deleted the original locations where applicable.

1 files changed, 0 insertions, 29 deletions

diff --git a/doc/project/governance.bb b/doc/project/governance.bb
deleted file mode 100644
index 4c1538b4b..000000000
--- a/doc/project/governance.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-[h2]$Projectname Governance[/h2]
-
-Governance relates to the management of a project and particularly how this relates to conflict resolution.
-
-[h3]Community Governance[/h3]
-
-The project is maintained and decisions made by the 'community'. The governance structure is still evolving. Until the structure is finalised, decisions are made in the following order:
-
-[ol]
-[*] Lazy Consensus
-
-If a project proposal is made to one of the community governance forums and there are no serious objections in a "reasonable" amount of time from date of proposal (we usually provide 2-3 days for all interested parties to weigh in), no vote needs to be taken and the proposal will be considered approved. Some concerns may be raised at this time, but if these are addressed during discussion and work-arounds provided, it will still be considered approved. 
-
-[*] Veto
-
-Senior developers with a significant history of project commits may veto any decision. The decision may not proceed until the veto is removed or an alternative proposal is presented.
-
-[*] Community Vote
-
-A decision which does not have a clear mandate or clear consensus, but is not vetoed, can be taken to a community vote. At present this is a simple popular vote in one of the applicable community forums.  At this time, popular vote decides the outcome. This may change in the future if the community adopts a 'council' governance model. This document will be updated at that time with the updated governance rules. 
-[/ol]
-
-Community Voting does not always provide a pleasant outcome and can generate polarised factions in the community (hence the reason why other models are under consideration). If the proposal is 'down voted' there are still several things which can be done and the proposal re-submitted with slightly different parameters (convert to an addon, convert to an optional feature which is disabled by default, etc.). If interest in the feature is high and the vote is "close", it can generate lots of bad feelings amongst the losing voters. On such close votes, it is [b]strongly recommended[/b] that the proposer take steps to address any concerns that were raised and re-submit.
-
-  
-
- 
-
-