diff --git a/compendium/family_community/community_management.md b/compendium/family_community/community_management.md deleted file mode 100644 index e0c523e..0000000 --- a/compendium/family_community/community_management.md +++ /dev/null @@ -1,70 +0,0 @@ -# Community Management - -## 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 -collaboration. -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 - -### 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 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: