Conversation
|
|
||
| ## 2. Decisions. | ||
| ### 2.2 User | ||
| Users have a need for the project. They are essential to the project’s purpose and they are the business domain experts. There are no technical requirements to become a user, as the Netzgrafik-Editor is available as a publicly accessible service. |
There was a problem hiding this comment.
I would not limit this to technical requirements, but stress that by the open source definition there are no limitations on using the project, because the license gives permission to use it for any purpose by any party.
The reasoning is not that it's a publicly accessible service, but because it's released as open source software. Service might even be misleading, because an instance as hosted service might be subject to limitations. The deliverable of the project is the software not a service.
There was a problem hiding this comment.
"There are no requirements to become a user, as the Netzgrafik-Editor licensing gives permission to use it for any purpose by any party."
There was a problem hiding this comment.
What about "There are no requirements or restrictions for using the Netzgrafik-Editor. As open source software, its license grants anyone the right to use it for any purpose.”
| Users have a need for the project. They are essential to the project’s purpose and they are the business domain experts. There are no technical requirements to become a user, as the Netzgrafik-Editor is available as a publicly accessible service. | ||
|
|
||
| **2.1. Consensus-Based Decision Making**. Projects make decisions through consensus of the Maintainers. While explicit agreement of all Maintainers is preferred, it is not required for consensus. Rather, the Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Contributors and nature of support and objections. The Maintainers will document evidence of consensus in accordance with these requirements. | ||
| The project encourages users to participate in the community as much as possible. Common ways users contribute include: |
There was a problem hiding this comment.
I would not talk about "contribute" here to not create confusion with the category "contributor".
I would also stress that a user is not obliged to participate. But it is encouraged to engage with the project as users to get the full benefit of it being an open source community.
There was a problem hiding this comment.
"Users are invited to support the project by:"
There was a problem hiding this comment.
Maybe "Users are invited to get engaged with the project by:"? Support sounds more passive, but active participation is what is the goal, right?
| - promoting the project (e.g. linking from websites or raising awareness by word of mouth) | ||
| - informing developers about strengths and weaknesses from a user perspective | ||
| - providing community support | ||
| Users who remain engaged with the project may become Contributors over time. |
There was a problem hiding this comment.
Is this meant as a requirement, that users first have to demonstrate engagement, before they are allowed to contribute? Probably not, as somebody showing up with a pull request as a first engagement probably would be welcome, right?
There was a problem hiding this comment.
Proposal: "Users may become Contributors".
|
|
||
| **2.2. Appeal Process**. Decisions may be appealed by opening an issue and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time. If the Maintainers deny the appeal, the appeal may be brought before the Technical Committee, who will also respond in writing in a reasonable time. | ||
| ### 2.3 Contributor | ||
| Contributors form a broad group, ranging from users contributing documentation and requirements to engineers contributing to the platform’s codebase, infrastructure, and architecture. Contributors may act on behalf of an organisation or independently. Contributors do not have direct write access to the main repository. They may create issues, comment on issues, fork the repository, and submit pull requests. |
There was a problem hiding this comment.
I would be a bit more explicit about what a contribution is. I would take the boundary, where it's about material to be included in the project, i.e. code, documentation or any other content which becomes part of the code base. This is where there is a legal boundary because the project needs the rights under copyright to include this in version control or release artifacts.
Other things such as issues, comments, etc. are more a communication artifact, so that could be more on the user's side. Or contributors acting as reviewers and similar roles.
There was a problem hiding this comment.
I see the point, but I don’t agree with the solution yet. For me, there’s a big difference between someone who is directly involved in the process of creating software and someone who uses it (e.g., a tester, a reviewer who provides direct feedback but doesn’t change the code would then be a user).
Of course, the issue of copyright is important and must be respected. In this sense, contributors of code or documentation bear greater responsibility, and they must hold the copyright to the code or text so they can grant the project the rights to use it. However, to me this is an important point that should be addressed explicitly.
There was a problem hiding this comment.
Who could help us to find a well fitted formulation? I am not sure that I could provide the solution...
There was a problem hiding this comment.
We had a discussion in the technical committee and agreed that a useful model would be to talk about participants here. This includes contributors of code and other material which is worked on in git, but also includes people who engage with the project through bug reports, comments, answering questions, etc. This terminology is also consistent how GitHub uses it in the UI.
So we would have something like a funnel from users to participants (including contributors) to committers to maintainers. This forms the community and people are encouraged to move to more engagement.
|
|
||
| ## 3. How We Work. | ||
| ### 2.4 Committer | ||
| Committers are trusted contributors with recognised expertise in their domain and in the project’s infrastructure. They have permission to modify source code or documentation and may commit directly to the main repository. In practice, they can create branches, submit pull requests, and perform code reviews. A Contributor may be nominated for Committer status by an existing Committer. Appointment requires confirmation by a Maintainer. |
There was a problem hiding this comment.
I would leave out the "In practice ..." sentence, because in practice everybody can do that, in the case of pull requests and code reviews even on the main repo.
Can a committer be appointed by a single maintainer or does it need the decision by the maintainers as a group?
There was a problem hiding this comment.
I agree with the "In practice" sentence!
I wasn’t really sure about the appointment of committers. In a large project, it can be cumbersome to ask everyone. A solution could be a four-eyes principle—that is, the appointment of a committer must be at least confirmed by a second maintainer.
There was a problem hiding this comment.
A four-eyes principle sounds reasonable to me.
|
|
||
| **3.2. Balance**. The development process should balance the interests of Contributors and other stakeholders. Contributors from diverse interest categories shall be sought with the objective of achieving balance. | ||
| ### 2.6 Business Domain Steward | ||
| The business domain stewards are responsible to bring the expertise of the real-world business into the open source project. They understand the value the software provides, how it is used in practice, and which needs matter most to users. They guide feature prioritisation based on business relevance, refine requirements, validate releases from a business perspective, and contribute to documentation, training, and enablement. Business Domain Stewards are accountable for artefacts directed at users. New Business Domain Stewards are appointed by existing Stewards and confirmed by the PSC. |
There was a problem hiding this comment.
What means "guide feature prioritization" in practice?
What means "accountable" for artifacts in practice?
There was a problem hiding this comment.
I would also like to have them included in the "Definition of Ready": https://github.com/OpenRailAssociation/netzgrafik-editor-frontend/blob/main/.github/ISSUE_TEMPLATE/3-design-document.yaml
There was a problem hiding this comment.
Is "guide feature priorization" refering to set for each feature a Milestone?
There was a problem hiding this comment.
@cornelius:
to guide: I was thinking abour: "...provides direction on which features should be worked on first and why, without having sole authority to decide"
accountable: "..is responsible for the quality" ->That means he doesn't have to create them, but he has to review them and decide whether to merge them
There was a problem hiding this comment.
@louisgreiner ouis: Is "guide feature priorization" refering to set for each feature a Milestone?
I don't know what is truly practical and would do justice to an agile way of working. I could imagine assigning features to the next 1–3 milestones in order to agree on a rough plan. This is a point for discussion.
There was a problem hiding this comment.
Regarding the milestones, I thought on the same workflow. Then the project will have a proper roadmap, prioritized using business knowledge, and people can use it directly. This means we have to anticipate the next milestones, but this is something we already do with @aiAdrian. Sounds great to me.
|
|
||
| Amendments to this governance policy may be made by affirmative vote of 2/3 of all Maintainers, with approval by the Technical Committee. | ||
| ## 4. No Confidentiality. | ||
| Information disclosed in connection with any project activity, including meetings, contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. |
There was a problem hiding this comment.
Is there a reason why you removed the "but not limited" from the original template text?
| Information disclosed in connection with any project activity, including meetings, contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. | ||
|
|
||
| ## 5. Amendments. | ||
| Major Changes to this governance policy require an affirmative vote of two-thirds of all Maintainers and Business Domain Stewards, with approval by the Technical Committee. |
There was a problem hiding this comment.
Wouldn't that be something for the PSC?
louisgreiner
left a comment
louisgreiner
left a comment
There was a problem hiding this comment.
Except the small typos, this looks quite clear to me. Thanks a lot for this, I'm thrilled to be part of it! :)
Co-authored-by: Louis Greiner <57864277+louisgreiner@users.noreply.github.com>
Co-authored-by: Cornelius Schumacher <cornelius.schumacher@deutschebahn.com>
Co-authored-by: Cornelius Schumacher <cornelius.schumacher@deutschebahn.com>
Co-authored-by: Louis Greiner <57864277+louisgreiner@users.noreply.github.com>
Co-authored-by: Louis Greiner <57864277+louisgreiner@users.noreply.github.com>
louisgreiner
left a comment
louisgreiner
left a comment
There was a problem hiding this comment.
This looks good to me. @emersion might be interested in the matter (he's currently off for a few days tho)
cornelius
left a comment
cornelius
left a comment
There was a problem hiding this comment.
It's a good draft. I commented on a couple of sections and tried to answer all questions which were directed to me.
4 participants
New version of the Netzgrafik-Editor governance