Update README.md #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
m-mohr
commented
Oct 2, 2020
|
|
||
| Author: Edzer Pebesma, mostly copied from https://gdal.org/development/rfc/rfc1_pmc.html#rfc-1 | ||
| This document describes how the openEO Project Steering Committee determines membership, and makes decisions on openEO project issues. The openEO project is concerned with all repositories (software and specifications etc.) found under https://github.com/Open-EO. |
There was a problem hiding this comment.
Clarified here that it's no just software, but all repositories (software and specs)
m-mohr
commented
Oct 2, 2020
| Author: Edzer Pebesma, mostly copied from https://gdal.org/development/rfc/rfc1_pmc.html#rfc-1 | ||
| This document describes how the openEO Project Steering Committee determines membership, and makes decisions on openEO project issues. The openEO project is concerned with all repositories (software and specifications etc.) found under https://github.com/Open-EO. | ||
|
|
||
| In brief the committee votes on proposals on https://github.com/Open-EO/PSC/issues. Proposals are available for review for at least two business days, and a single veto is sufficient to delay progress though ultimately a majority of members can pass a proposal. |
There was a problem hiding this comment.
Changed link to the issue tracker directly as we'll propose and vote there.
m-mohr
commented
Oct 2, 2020
|
|
||
| ## Summary | ||
| * Jeroen Dries (@jdries) |
m-mohr
commented
Oct 2, 2020
|
|
||
| This document describes how the openEO Project Steering Committee determines membership, and makes decisions on openEO project issues. The openEO project is concerned with all software found under https://github.com/Open-EO. | ||
| In brief the committee votes on proposals on https://github.com/Open-EO/PSC. Proposals are available for review for at least two (German) business days, and a single veto is sufficient to delay progress though ultimately a majority of members can pass a proposal. | ||
| The current list will be maintained by the openEO chair on this page and will be published to the openEO web pages, too. |
There was a problem hiding this comment.
Changed this. Should be maintained here, I'll implement that this will be automatically included in the homepage.
m-mohr
commented
Oct 2, 2020
| 3. Respondents may vote “+1” to indicate support for the proposal and a willingness to support implementation. | ||
| 4. Respondents may vote “-1” to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days. | ||
| 5. A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicates mild support, but has no effect. | ||
| 1. Proposals are written up and submitted on https://github.com/Open-EO/PSC/issues/new for discussion and voting, by any interested party, not just committee members. |
There was a problem hiding this comment.
Directly link to the page where you can write new proposals
m-mohr
commented
Oct 2, 2020
| 4. Respondents may vote “-1” to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days. | ||
| 5. A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicates mild support, but has no effect. | ||
| 1. Proposals are written up and submitted on https://github.com/Open-EO/PSC/issues/new for discussion and voting, by any interested party, not just committee members. | ||
| 2. Proposals need to be available for review for at least two business days before a final decision can be made. Public holidays count as business days. |
There was a problem hiding this comment.
Beforehand it was "(German) business days". That is still ambiguous due to different public holidays in different federal states (e.g. NRW). So I'd just say we ignore business days at all. As there are sometimes two public holidays in a row (e.g. Christmas), we may want to decide that "at least two business days" is changed to "at least three business days". Opinions?
m-mohr
commented
Oct 2, 2020
README.md
Outdated
| 6. Anyone may comment on proposals on the list, but only members of the Project Steering Committee’s votes will be counted. | ||
| 7. A proposal will be accepted if it receives +2 (including the proposer) and no vetoes (-1) or has not received enough votes in 14 business days. | ||
| 7. A proposal will be accepted if it receives +2 (including the proposer) and no vetoes (-1) or has not received enough votes in 10 business days. |
There was a problem hiding this comment.
14 business days seems strange. I think this was 14 days before, which would be 10 business days, I think. By the way, is Saturday a business day? We should clarify. Otherwise we may just go with two weeks (i.e. 14 days).
m-mohr
commented
Oct 2, 2020
|
|
||
| Generally speaking, technical decisions should be made by consensus within openEO components. However, if a decision cannot be decided by consensus of the committers involved in the component, any committer can request the decision be brought to a vote of the openEO PSC. Technical decision that would be suitable for such a process include: | ||
|
|
||
| * Any change to PSC membership (new members, removing inactive members) | ||
| * Anything that could cause backward compatibility issues in API, process specifications or shared software components. | ||
| * Anything that could cause backward compatibility issues in normative specifications (e.g., API or process specifications). |
There was a problem hiding this comment.
We have a remark below on the review process for shared software components. so it doesn't make sense to go with them through the PSC, too. So I changed to just "normative specifications" (i.e. OpenAPI file, but not assisting documents like the recommended error message list). By the way, this also includes the UDF API!
m-mohr
commented
Oct 2, 2020
|
|
||
| * The Chair is the ultimate adjudicator if things break down. | ||
| * The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances vetoers need to be convinced to withdraw their veto. We are trying to reach consensus. | ||
| * Software components that at least two other software repositories under https://github.com/Open-EO depend on, must implement a review system for breaking changes (e.g. GitHub Pull Request Approvals) that require a certain number of approvals: 2 dependants require 1 approval, more than 2 dependants require 2 approvals. | ||
| * Software components that at least two other software repositories under https://github.com/Open-EO depend on, must implement a review system for breaking changes (e.g. GitHub Pull Request Approvals) that require a certain number of approvals: 2 dependants require 1 approval, more than 2 dependants require 2 approvals. Exceptions for this must go through the PSC process. |
There was a problem hiding this comment.
I guess there could be cases where there exceptions are okay, but that should be discussed in the PSC.
m-mohr
commented
Oct 2, 2020
| @@ -52,17 +59,10 @@ Any member of the openEO mailing list may nominate someone for committee members | |||
|
|
|||
| ### Stepping Down | |||
|
|
|||
| If for any reason a PSC member is not able to fully participate then they certainly are free to step down. If a member is not active (e.g. no voting, no IRC or email participation) for a period of 12 months then the PSC reserves the right to seek nominations to fill that position. Should that person become active again then they would certainly be welcome, but would require a nomination. | |||
| If for any reason a PSC member is not able to fully participate then they certainly are free to step down. If a member is not active (e.g., no voting or email participation) for a period of 12 months then the PSC reserves the right to seek nominations to fill that position. Should that person become active again then they would certainly be welcome, but would require a nomination. | |||
There was a problem hiding this comment.
I doubt we'll set up an IRC channel? :-D I guess I'm also the last generation to actually know IRC... ;-)
m-mohr
commented
Oct 7, 2020
m-mohr
commented
Oct 7, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I went through it again and made some changes, justifications/explanations in the comments below...
I also changed the structure a bit, as I plan to just import this file into the openEO web page automatically, so that we don't need to maintain it in two places.