From dfbd8332d2f3c98ca193799d52f7032554e18f04 Mon Sep 17 00:00:00 2001 From: vismayajochem Date: Wed, 24 Jun 2026 13:29:39 +0200 Subject: [PATCH 1/5] Improve OEF-SC text and add decision making #96 --- compendium/family_community/community_management.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/compendium/family_community/community_management.md b/compendium/family_community/community_management.md index e0c523e..05ac01b 100644 --- a/compendium/family_community/community_management.md +++ b/compendium/family_community/community_management.md @@ -6,7 +6,8 @@ Community Management is critical for the success of the Open Energy Family. The Community Manager fosters a collaborative environment and communicates between the community and the development team. They gather feedback, prioritize requests, and organize events that facilitate engagement and -collaboration. +collaboration. They have an overview over all ongoing and planned developments, hold knowledge and transfer it if needed. +The Community Manager holds the right to veto any decision. This applies in development meetings as well as in the Advisory Board. Effective Community Management ensures that the framework meets the needs of its users and adapts to the changing needs of the energy research community. @@ -52,6 +53,9 @@ to exchange information and review planned and completed tasks. 5. Develop and advance the vision of the OEFamily - Developing and pursuing strategies to expand and improve the functionality - Identifying future areas of application and integrating new technologies and developments + +#### Decision making process of the OEF-SC +Before every decision there were enough information given to all members of the OEF-SC to make an informed decision on the issue at hand. Every institute, represented through a present member at the meeting, has one vote. One can vote in favor or against the proposal or sustain. The proposal is agreed to when more than have of the votes are in favor of it. Only the Community Manager has the power to veto an otherwise accepted proposal. ### OEO-SC From e27edffd21ef70bd9acf9cb15ec6a38413a03e5d Mon Sep 17 00:00:00 2001 From: vismayajochem Date: Wed, 24 Jun 2026 13:34:01 +0200 Subject: [PATCH 2/5] Add introduction #96 --- compendium/family_community/community_management.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/compendium/family_community/community_management.md b/compendium/family_community/community_management.md index 05ac01b..e29ea7d 100644 --- a/compendium/family_community/community_management.md +++ b/compendium/family_community/community_management.md @@ -1,8 +1,9 @@ # Community Management +Community Management is critical for the success of the Open Energy Family. Therefor the Community Management is split into three main areas which all hold specific roles and responsabilities. + ## Community Manager -Community Management is critical for the success of the Open Energy Family. The Community Manager fosters a collaborative environment and communicates between the community and the development team. They gather feedback, prioritize requests, and organize events that facilitate engagement and @@ -53,8 +54,9 @@ to exchange information and review planned and completed tasks. 5. Develop and advance the vision of the OEFamily - Developing and pursuing strategies to expand and improve the functionality - Identifying future areas of application and integrating new technologies and developments - + #### Decision making process of the OEF-SC + Before every decision there were enough information given to all members of the OEF-SC to make an informed decision on the issue at hand. Every institute, represented through a present member at the meeting, has one vote. One can vote in favor or against the proposal or sustain. The proposal is agreed to when more than have of the votes are in favor of it. Only the Community Manager has the power to veto an otherwise accepted proposal. ### OEO-SC @@ -72,3 +74,6 @@ through GitHub. 3. Networking to external ontology development teams and with the OEO user community 4. Foster exchange and discussions 5. Arbitration and decision board + +## + From 19ea7d033f8d8041ea003e2f1b0ff3bf8d9c4e3a Mon Sep 17 00:00:00 2001 From: vismayajochem Date: Wed, 24 Jun 2026 14:01:11 +0200 Subject: [PATCH 3/5] Add Developer Meeting #96 --- .../family_community/community_management.md | 23 ++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/compendium/family_community/community_management.md b/compendium/family_community/community_management.md index e29ea7d..4045588 100644 --- a/compendium/family_community/community_management.md +++ b/compendium/family_community/community_management.md @@ -75,5 +75,26 @@ through GitHub. 4. Foster exchange and discussions 5. Arbitration and decision board -## +## OEO-Developer-Meeting +Developer Meetings (OEO-Dev) are the basic work meetings while working on project associated with the OEFamily. They happen for every project independently in an interval suited for the pace of this project. The members of the meetings are the developer, who actively work and program on the concerned project. + +### Tasks of the OEO-DeveloperMeeting +1. progress exchange + - informing other developers about the own progress + - coordinating furhter steps +2. project planing + - planning next steps for agreed upon developments + - dividing tasks among the developers +3. decision making + - discussing issues + - finding consensus agreements on issues relevant for the development of the project +4. communicating with SC + - a member, who is also a member of the relevant SC, transfers information + - giving proposals or needed decisons to the SC + +### Decision making process of the dev-m + +Every developer present at the meeting has a vote. Since everybody is working on the project, affiliation to an institute or role within it (e.g. project manager, student, WiMi) is not relevant. The goal is to reach a consensus agreement. Meaning, that through the discussion during the meeting a decision can be made to which everybody present can easily agree to. If such a decision is not reached and there is a dispute, the proposal and the concerns are brought to the OEF-SC (or the OEO-SC when the decision is regarding only the OEO). Then the SC must mediate and decide on further steps in that issue. + +Any major decision has to be brought to the SC. If there is a consensus within the Developer Meeting, a proposal can be given as a strong advice. From d21330dc7304b998a1b6c26c7166d7fa7243f86d Mon Sep 17 00:00:00 2001 From: vismayajochem Date: Wed, 24 Jun 2026 14:05:22 +0200 Subject: [PATCH 4/5] Fix spelling #96 --- .../family_community/community_management.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/compendium/family_community/community_management.md b/compendium/family_community/community_management.md index 4045588..f3aced2 100644 --- a/compendium/family_community/community_management.md +++ b/compendium/family_community/community_management.md @@ -77,23 +77,23 @@ through GitHub. ## OEO-Developer-Meeting -Developer Meetings (OEO-Dev) are the basic work meetings while working on project associated with the OEFamily. They happen for every project independently in an interval suited for the pace of this project. The members of the meetings are the developer, who actively work and program on the concerned project. - -### Tasks of the OEO-DeveloperMeeting -1. progress exchange - - informing other developers about the own progress - - coordinating furhter steps -2. project planing - - planning next steps for agreed upon developments - - dividing tasks among the developers -3. decision making - - discussing issues - - finding consensus agreements on issues relevant for the development of the project -4. communicating with SC - - a member, who is also a member of the relevant SC, transfers information - - giving proposals or needed decisons to the SC - -### Decision making process of the dev-m +Developer Meetings (OE-Dev) are the basic work meetings while working on project associated with the OEFamily. They happen for every project independently in an interval suited for the pace of this project. The members of the meetings are the developer, who actively work and program on the concerned project. + +### Tasks of the OE-Dev +1. Progress exchange + - Informing other developers about the own progress + - Coordinating furhter steps +2. Project planing + - Planning next steps for agreed upon developments + - Dividing tasks among the developers +3. Decision making + - Discussing issues + - Finding consensus agreements on issues relevant for the development of the project +4. Communicating with SC + - A member, who is also a member of the relevant SC, transfers information + - Giving proposals or needed decisons to the SC + +### Decision making process of the OE-Dev Every developer present at the meeting has a vote. Since everybody is working on the project, affiliation to an institute or role within it (e.g. project manager, student, WiMi) is not relevant. The goal is to reach a consensus agreement. Meaning, that through the discussion during the meeting a decision can be made to which everybody present can easily agree to. If such a decision is not reached and there is a dispute, the proposal and the concerns are brought to the OEF-SC (or the OEO-SC when the decision is regarding only the OEO). Then the SC must mediate and decide on further steps in that issue. From 29fce361e1de3abd300f1181bf60344cdd4fe5c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludwig=20H=C3=BClk?= Date: Mon, 13 Jul 2026 23:23:42 +0200 Subject: [PATCH 5/5] Add updated governance version #96 --- .../family_community/community_management.md | 100 -------- compendium/family_community/contact.md | 4 + compendium/family_community/governance.md | 213 ++++++++++++++++++ .../minutes/YYYY-MM-DD_OEFamily-SC_meeting.md | 47 ++++ .../proposals/2026-07-16_oeep_governance.md | 107 +++++++++ .../proposals/YYYY-MM-DD_oeep_topic.md | 62 +++++ mkdocs.yml | 2 +- 7 files changed, 434 insertions(+), 101 deletions(-) delete mode 100644 compendium/family_community/community_management.md create mode 100644 compendium/family_community/governance.md create mode 100644 compendium/family_community/minutes/YYYY-MM-DD_OEFamily-SC_meeting.md create mode 100644 compendium/family_community/proposals/2026-07-16_oeep_governance.md create mode 100644 compendium/family_community/proposals/YYYY-MM-DD_oeep_topic.md diff --git a/compendium/family_community/community_management.md b/compendium/family_community/community_management.md deleted file mode 100644 index f3aced2..0000000 --- a/compendium/family_community/community_management.md +++ /dev/null @@ -1,100 +0,0 @@ -# Community Management - -Community Management is critical for the success of the Open Energy Family. Therefor the Community Management is split into three main areas which all hold specific roles and responsabilities. - -## Community Manager - -The Community Manager fosters a collaborative environment and communicates -between the community and the development team. They gather feedback, -prioritize requests, and organize events that facilitate engagement and -collaboration. They have an overview over all ongoing and planned developments, hold knowledge and transfer it if needed. -The Community Manager holds the right to veto any decision. This applies in development meetings as well as in the Advisory Board. -Effective Community Management ensures that the framework meets the needs of -its users and adapts to the changing needs of the energy research community. - -## Steering Committees - -To accompany the ongoing development and success of the Community, -two steering committees have been established: -the OEO Steering Committee (OSO-SC) -and the OEFamily Steering Committee (OEFamily-SC). -Both steering committees play a critical role in guiding the development -of the Open Energy Family and the OEO. -Their oversight and strategic direction help to ensure that the framework -and ontology remain relevant and useful to the energy research community. - -You can find the dates on the [Contact](../contact/) page. - -### OEFamily-SC - -The OEFamily-SC is responsible for the overall development and strategic -direction of the Open Energy Family framework. -The committee works closely with the core development team to ensure that the -framework meets the needs of its users and remains aligned with the goals -of the project. It meets regularly via conference calls and in-person meetings -to exchange information and review planned and completed tasks. - -#### Tasks of the OEFamily-SC - -1. Maintain an overview of the OEFamily and its structure - - Identify existing and planned functions and components - - Determine responsibilities and time lines for development - - Identify similar projects in the field -2. Support the development of the OEFamily - - Support in prioritizing tasks and decisions about the development progress - - Ensuring the sustainability of the development through continuous feedback and testing -3. Act as a mediator and decision-making body - - Enforce the code of conduct for interpersonal issues - - Utilize the Dev-Meeting processes for content-related disputes -4. Support external communication efforts - - Represent the OEFamily at conferences and public events - - Maintain and expand networks, identifying key individuals and organizations who should be informed about the OEFamily and OEP - - Foster connections between users and developers - - Communicate with funding bodies and government ministries -5. Develop and advance the vision of the OEFamily - - Developing and pursuing strategies to expand and improve the functionality - - Identifying future areas of application and integrating new technologies and developments - -#### Decision making process of the OEF-SC - -Before every decision there were enough information given to all members of the OEF-SC to make an informed decision on the issue at hand. Every institute, represented through a present member at the meeting, has one vote. One can vote in favor or against the proposal or sustain. The proposal is agreed to when more than have of the votes are in favor of it. Only the Community Manager has the power to veto an otherwise accepted proposal. - -### OEO-SC - -The OEO-SC is responsible for overseeing the development of the OEO -and ensuring its adoption in currently running and planned projects. -The committee meets regularly via conference calls and in-person meetings -to exchange information and review planned and completed tasks. -The committee also maintains a continuous exchange with ontology developers -through GitHub. - -#### Tasks of the OEO-SC -1. Provide advice and support for OEO development -2. Guide basic design decisions -3. Networking to external ontology development teams and with the OEO user community -4. Foster exchange and discussions -5. Arbitration and decision board - -## OEO-Developer-Meeting - -Developer Meetings (OE-Dev) are the basic work meetings while working on project associated with the OEFamily. They happen for every project independently in an interval suited for the pace of this project. The members of the meetings are the developer, who actively work and program on the concerned project. - -### Tasks of the OE-Dev -1. Progress exchange - - Informing other developers about the own progress - - Coordinating furhter steps -2. Project planing - - Planning next steps for agreed upon developments - - Dividing tasks among the developers -3. Decision making - - Discussing issues - - Finding consensus agreements on issues relevant for the development of the project -4. Communicating with SC - - A member, who is also a member of the relevant SC, transfers information - - Giving proposals or needed decisons to the SC - -### Decision making process of the OE-Dev - -Every developer present at the meeting has a vote. Since everybody is working on the project, affiliation to an institute or role within it (e.g. project manager, student, WiMi) is not relevant. The goal is to reach a consensus agreement. Meaning, that through the discussion during the meeting a decision can be made to which everybody present can easily agree to. If such a decision is not reached and there is a dispute, the proposal and the concerns are brought to the OEF-SC (or the OEO-SC when the decision is regarding only the OEO). Then the SC must mediate and decide on further steps in that issue. - -Any major decision has to be brought to the SC. If there is a consensus within the Developer Meeting, a proposal can be given as a strong advice. diff --git a/compendium/family_community/contact.md b/compendium/family_community/contact.md index 58b4da0..6c3d862 100644 --- a/compendium/family_community/contact.md +++ b/compendium/family_community/contact.md @@ -42,6 +42,10 @@ Every 2nd week, on Tuesdays, from 14:00 to 14:00 CEST. Every 2nd week, on Thursday, from 10:00 - 12:00 CEST +### open-mastr-dev + +Every 3rd week, on Thursday, from 15:00 - 16:00 CEST + ## Steering Committee Meetings ### OEFamily-SC diff --git a/compendium/family_community/governance.md b/compendium/family_community/governance.md new file mode 100644 index 0000000..d5fe3aa --- /dev/null +++ b/compendium/family_community/governance.md @@ -0,0 +1,213 @@ +# Governance of the Open Energy Family + +This document defines the roles, bodies, and decision-making procedures of the +Open Energy Family (OEFamily). It is the authoritative reference. Operational +details such as meeting dates, mailing lists, and contacts are kept on the +[Contact page](../contact/). + + +## 1. Scope and principles + +Four principles underlie the structure. + +1. Contribution grounds participation. Within a development group, a say in + decisions follows from the work done, not from institutional affiliation or + title. +2. Consensus is the default. A formal vote is the fallback when consensus + cannot be reached, not the normal case. +3. Decisions, minutes, and votes are documented publicly in the Compendium. + Only matters that protect individuals, such as Code of Conduct cases, are + kept private. +4. This document changes only through the procedure in Section 7. + +## 2. Membership and voting + +An institution joins the OEFamily by contributing to an OEFamily project and +stating this to the OEFamily-SC. Each member institution names a representative +and a deputy for votes. + +Voting rights follow active contribution. In practice the institutions +currently doing the work hold the vote; standing is not affected by an +occasional absence. An institution leaves either by its own statement or after +about a year without any contribution. Departures are recorded in the minutes. + +## 3. Roles + +### 3.1 Community Manager (CM) + +The Community Manager connects the community and the development groups. +The role coordinates and moderates. +The CM collects and bundles feedback from the community and carries it to the bodies, keeps an +overview of ongoing and planned development and passes on knowledge through +onboarding, documentation, and references, organises and moderates meetings and +community formats, and points out duplicated effort between groups. + +The CM has the right to speak and to submit motions in the development groups +and in both committees. Before an adopted decision takes effect, the CM may ask +the responsible committee to reconsider it once (Section 5.5). This is a +suspensive request, not a power to block. + +The OEFamily-SC appoints the CM for a term of one year, with reappointment +possible, and may remove the CM by a two-thirds majority. If the position is +vacant, the OEFamily-SC names an interim replacement. + +### 3.2 Maintainer + +A maintainer carries operational responsibility for a project or component, +including repository rights, releases, and review. Maintainers vote in the +development group of their project. + +### 3.3 Contributor + +A contributor works actively on a project through code, ontology terms, data, +documentation, or review. Contributors vote in the development group of their +project. + +## 4. Bodies + +The OEFamily has one decision-making committee, one advisory committee, and development groups. + +### 4.1 OEFamily Steering Committee (OEFamily-SC) + +The OEFamily-SC is the decision-making body for the framework as a whole. It +sets strategic direction and takes the binding decisions that concern the family +across projects. + +1. Keep an overview of the OEFamily: its functions, components, + responsibilities, and timelines, and related work in the field. +2. Support development: advise on priorities and keep the work sustainable + through continued feedback and testing. +3. Mediate and decide: enforce the Code of Conduct in interpersonal conflict + and decide content disputes escalated from the development groups. +4. Represent the OEFamily externally at conferences and in public, maintain + networks, and communicate with funding bodies and ministries. +5. Develop the longer-term direction: pursue strategies to extend the + functionality and identify future fields of application. + +### 4.2 OEO Steering Committee (OEO-SC) + +The OEO-SC guides the development of the Open Energy Ontology (OEO) and its use +across projects. Its role is advisory: it gives recommendations, guides basic +design decisions, maintains contact with external ontology teams and the OEO +user community, and serves as the first point for arbitration in OEO questions. +Binding decisions that reach beyond the OEO-DEV group are referred to the +OEFamily-SC (Section 5.4). + +### 4.3 Development groups: OEP-DEV and OEO-DEV + +Development takes place in specific groups: +Currently, there are 3 active developer teams: +OEP-DEV for the Open Energy Platform, +OEO-DEV for the Open Energy Ontology, and +open-mastr-dev for open-mastr. +Each sets its own pace and organises itself. +The groups work autonomously: they settle the technical and content +questions within their scope and involve the committees only when a question +exceeds that scope (Section 5.6) or when they seek advice or arbitration. + +The members of a group are the people who work on it actively. +The groups exchange progress and coordinate next steps, plan and distribute tasks, +and reach decisions by consensus within their scope. +A member who also sits on the relevant committee carries information both +ways and brings forward proposals or decisions that the committee needs to take. + +## 5. Decision-making + +### 5.1 Responsibility + +Technical and content questions inside a project are settled by its development +group. Advice and recommendations on the OEO come from the OEO-SC. Binding, +framework-wide decisions rest with the OEFamily-SC. Where a question touches both +the OEO and the framework, the OEFamily-SC decides after hearing the OEO-SC. + +### 5.2 Development groups: consensus and lazy consensus + +Everyone present and actively contributing has one vote; the aim is consensus. +Between meetings, lazy consensus applies: a proposal is announced in the open +(issue or discussion) and carried out after 1 week unless a reasoned objection +is raised. Silence counts as assent; a reasoned objection returns the question +to discussion. If no consensus forms, the proposal and the objections go to the +relevant committee, the OEO-SC for OEO questions and otherwise the OEFamily-SC. + +### 5.3 OEFamily-SC: voting + +Before a decision, members receive enough information in time to decide. Each +member institution present has one vote. The committee can decide when at least +half of the voting institutions are represented. Members vote for, against, or +abstain. A proposal passes when more than half of the votes cast for and against +are in favour; abstentions count towards the quorum but not the result. A tie +counts as rejection; the proposal may be revised and brought again. + +### 5.4 OEO-SC: recommendations + +The OEO-SC reaches its positions by consensus and, where it needs to state one +clearly, by an indicative vote. Its output is a recommendation to OEO-DEV or to +the OEFamily-SC, not a binding decision. Questions that exceed the OEO-DEV scope, +for example changes to published ontology identifiers or to shared interfaces, +are passed to the OEFamily-SC together with the committee's recommendation. + +### 5.5 Request for reconsideration by the Community Manager + +Before an adopted decision takes effect, the CM may ask the committee to +reconsider it once. The request is made in writing and gives a reason concerning +consistency, sustainability, or effect on the community. It defers the decision +and reopens discussion. At the next meeting the committee decides again under +Section 5.3, and the earlier decision stands if it is reaffirmed. The request is +a suspensive step, used sparingly, and does not replace argument on the +substance. + +### 5.6 Escalation from a development group to a committee + +A question leaves the development group when at least one of the following holds: + +- it affects more than the group's own project, such as shared interfaces or + infrastructure, or other OEFamily components; +- it changes public contracts such as APIs, data models, published ontology + identifiers, or URI and slug conventions; +- it commits the resources of several institutions or touches funding commitments; +- it changes policies, licences, or this governance; +- it remains contested within the group. + +Where the group holds a consensus, it forwards the proposal as a strong recommendation. + +## 6. Proposal process + +Decisions in the sense of Section 5.6 are written up as an Open Energy Enhancement Proposal (OEEP). +The mechanism follows the established pattern and is at +the same time the technical implementation in the Compendium (Section 8). + +1. Draft. The proposal is written as a Markdown document from the template + (`proposals/YYYY-MM-DD_oeep_topic.md`) and submitted as a pull request. +2. Discussion. Open commenting in the pull request and the linked GitHub + Discussion, for at least 4 weeks. +3. Final comment period. A named responsible person summarises the state, its + main points, compromises, and open objections, and starts the final comment + period. Full consensus is not required; what is required is the + absence of a strong, reasoned consensus against the proposal. +4. Decision. After the final comment period the responsible committee decides + under Section 5.3 (OEFamily-SC) or gives its recommendation (OEO-SC). + Outcomes are accepted, rejected, postponed, or returned to discussion. +5. Record. The outcome, date, and vote are recorded in the proposal and the + minutes. + +## 7. Amending this document + +A change to this document is itself an OEEP (Section 6) and needs adoption by the +OEFamily-SC with a two-thirds majority of the votes cast for and against. A +change that concerns only the OEO also requires hearing the OEO-SC. Each adopted +change is versioned and dated in the change log. + +## 8. Implementation in GitHub + +The governance is kept in the OEP Compendium: + +- `governance.md` is this document, the authoritative reference. +- `proposals/` holds OEEPs from the template, with an index listing status + (draft, discussion, final comment period, accepted, rejected, postponed). +- `proposals/template.md` is the template for new proposals. +- `minutes/` holds the archived minutes of both committees and of the + development groups where public. +- GitHub Discussions carry the discussion and final comment period, one thread + per proposal, linked from it. +- Issue labels are used for tracking. +- Admins require review by the OEFamily-SC for changes to `governance.md` and `proposals/`. diff --git a/compendium/family_community/minutes/YYYY-MM-DD_OEFamily-SC_meeting.md b/compendium/family_community/minutes/YYYY-MM-DD_OEFamily-SC_meeting.md new file mode 100644 index 0000000..1c79d7c --- /dev/null +++ b/compendium/family_community/minutes/YYYY-MM-DD_OEFamily-SC_meeting.md @@ -0,0 +1,47 @@ +# OEFamily-SC meeting, YYYY-MM-DD HH:MM + +File name: `YYYY-MM-DD_OEFamily-SC_meeting.md`. Kept in `minutes/` and public unless an item +protects individuals (for example a Code of Conduct case), which is minuted +separately and not published. + +## Attendance + +- Present: + - Name (institution) +- Apologies: + - Name (institution) +- Chair: Name (institution) +- Minutes: Name (institution) +- Voting institutions represented: of +- Quorum reached (at least half): yes | no + +## Agenda + +1. Project Updates +2. ... +3. News from Events +4. Next Meeting, Tasks, next chair + +## Items + +### 1. + +- Discussion: short account of the points raised. +- Proposal: what was put to the meeting. +- Decision: what was agreed. +- Vote (committee only): for , against , abstain . Passed | rejected. +- Reconsideration requested by the CM: no | yes (reason, and the result at this + or the next meeting). + + + +## Referrals + +- To a committee (from a development group), with the Section 5.6 criterion that + applied: +- To an OEEP (topic, responsible person): + +## Next meeting + +- Date: +- Chair: diff --git a/compendium/family_community/proposals/2026-07-16_oeep_governance.md b/compendium/family_community/proposals/2026-07-16_oeep_governance.md new file mode 100644 index 0000000..0a9e1e4 --- /dev/null +++ b/compendium/family_community/proposals/2026-07-16_oeep_governance.md @@ -0,0 +1,107 @@ +--- +title: "OEFamily-SC Governance Update" +status: draft # draft | discussion | accepted | rejected | postponed +body: OEFamily-SC # responsible committee: OEFamily-SC or OEO-SC +authors: + - "Ludwig, RLI>" +created: 2026-07-13 +discussion: "" +decided: "" # date, filled after the decision +--- + +# Open Energy Enhancement Proposal (OEEP) + +## Summary + +This proposal establishes a documented governance structure for the Open Energy Family. +It adopts `governance.md` as the authoritative reference and puts its +roles, bodies, and procedures into use. + +## Motivation + +The OEFamily has grown without a written governance. Roles and decisions exist +in practice, and the OEFamily-SC has taken decisions, but they are neither +documented nor transparent to people outside the immediate circle. An +undocumented structure is easy to run while the same few people are involved and +fragile once they change: there is no agreed way to reach a decision, to record +what was decided, or to change the rules themselves. +As the family and its funding context grow, this needs a stable and transparent +footing. The aim of this proposal is to provide one, without adding more +process than the work needs. + +## Proposal + +Adopt the governance documented in `governance.md` and put it into effect. + +**Current state** +- The structure is informal +- The OEFamily-SC decides in practice +- the OEO-SC has acted in an advisory role +- development happens in developer groups (OEP-DEV, OEO-DEV, open-mastr-dev). +- There is no defined quorum or majority, no record of decisions, no escalation rule between the +groups and the committees, and no procedure for changing the rules. +- A veto for the Community Manager was proposed earlier but was rejected. + +**Proposed state** +- `governance.md` defines: membership and voting +- roles of the Community Manager, maintainer, and contributor +- decision-making committee (OEFamily-SC), advisory committee (OEO-SC), and +autonomous development groups (OEP-DEV, OEO-DEV, open-mastr-dev) +- decision procedures (consensus and lazy consensus in the groups, voting in the OEFamily-SC, +recommendations from the OEO-SC, and a request for reconsideration by the +Community Manager) +- criteria for escalating a question from a group to a committee +- the OEEP process for larger decisions +- and a procedure for amending the governance +- Minutes and decisions are published in the Compendium + +**Difference** +- The change moves the family from an undocumented arrangement to a written one: defined quorum and majority instead of ad hoc counting +- written and archived minutes instead of the etherpad +- explicit escalation criteria instead of intuition +- an amendment rule for detailed discussions + +**Bootstrap** +This proposal establishes the OEEP process and therefore cannot follow it. +It is adopted directly by the OEFamily-SC, which already exists and +already takes decisions. From adoption, all further decisions follow the process +set out here. + +## Impact + +Immediate steps after adoption: + +- Elect a Community Manager at the next OEFamily-SC meeting, for the one-year + term defined in `governance.md`, Section 3.1. +- Put the OEEP process into use for decisions from adoption onward; this + proposal is the first entry in `proposals/`. +- Begin keeping and archiving minutes for all bodies in `minutes/`, and extend + the existing notes into the template format. + +Repository and structure: + +- Add `governance.md`, to the Compendium, with `proposals/` and `minutes/` and their templates. +- Add the issue labels `oeep`, and `governance`, and admin entry + requiring OEFamily-SC review for `governance.md` and `proposals/`. + +The proposal changes process, not code or data. It does not affect published +interfaces, ontology identifiers, or existing data models. + +## Open questions + +- Who is nominated as the first Community Manager. + + +## Final comment period + +Opened on: YYYY-MM-DD. Summary by : +- main points +- compromises reached +- open objections, if any + +## Decision + +- Body and date: +- Vote (for / against / abstain): +- Outcome: accepted | rejected | postponed | returned to discussion +- Request for reconsideration by the CM: none | raised (reason, result) diff --git a/compendium/family_community/proposals/YYYY-MM-DD_oeep_topic.md b/compendium/family_community/proposals/YYYY-MM-DD_oeep_topic.md new file mode 100644 index 0000000..e2f512c --- /dev/null +++ b/compendium/family_community/proposals/YYYY-MM-DD_oeep_topic.md @@ -0,0 +1,62 @@ +--- +title: "" +status: draft # draft | discussion | accepted | rejected | postponed +body: OEFamily-SC # responsible committee: OEFamily-SC or OEO-SC +authors: + - "" +created: YYYY-MM-DD +discussion: "" +decided: "" # date, filled after the decision +--- + +# Open Energy Enhancement Proposal (OEEP) + +This template follows the process in `governance.md`, Section 6. + +## Summary + +One paragraph. What is proposed and why, in plain terms. + +## Motivation + +The problem this addresses and who is affected. State why it needs a decision at +committee level rather than inside a development group, referring to the +criteria in `governance.md`, Section 5.6: + +- effect beyond one project (shared interfaces, infrastructure, other components) +- change to public contracts (APIs, data models, published identifiers, URI or + slug conventions) +- resources across institutions or funding commitments +- change to policy, licence, or governance +- an unresolved dispute within a development group + +## Proposal + +The concrete change. Be specific enough that someone else could implement it. +Include the current state, the proposed state, and the difference between them. + +## Impact + +- Interfaces and identifiers affected: +- Backward compatibility and migration: +- Effect on other OEFamily components (OEP, OEO): +- Resources and responsibilities: +- Licence or policy implications: + +## Open questions + +Points still to settle, so that reviewers can focus their comments. + +## Final comment period + +Opened on: YYYY-MM-DD. Summary by : +- main points +- compromises reached +- open objections, if any + +## Decision + +- Body and date: +- Vote (for / against / abstain): +- Outcome: accepted | rejected | postponed | returned to discussion +- Request for reconsideration by the CM: none | raised (reason, result) diff --git a/mkdocs.yml b/mkdocs.yml index e65fa94..8b5a7eb 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -58,7 +58,7 @@ nav: - Community: - Overview: family_community/index.md - Collaborative Development: family_community/collaborative_development.md - - Community Management: family_community/community_management.md + - Community Management and Governance: family_community/governance.md - Contact & Communication: family_community/contact.md - Knowledge Transfer: family_community/knowledge_transfer.md - Partner and Projects: