#2 Specify Governance repository Issues as public medium

[kpalang]

This PR specifies the Issues feature in Governance repository as the medium for amendments to OpenIntegrationEngine's governance document.

Closes #2

[tonygermano]

I would think an issue would be opened to identify a problem where a solution is not yet known or complete. I don't know if an issue should be required to propose a change. I think the PR itself, with or without a corresponding issue is the proposal. I'd say "a comment period of at least 14 days." That could lead to additional changes in the PR, which could take more time, and possibly restart the comment period.

We don't specify how long the Steering Committee has to approve the final changes once the 14 days is up, but I would imagine any comments that come in after the 14 days, but before getting full approval would be considered. There needs to be a cut-off at some point where the PR is accepted or closed if it does not have the votes.

This PR itself is a good example of why the issue should be used to identify a problem or shortcoming, but the PR should be considered the proposal. You can't give meaningful comments or approval until you see the actual proposed text.

[tonygermano]

Still not a fan of this one as written. None of the open PRs, including this one, conform to the requirements.

[tonygermano]

Can we just change this to a Pull Request instead of an issue? I don't have a problem with including the amendment label.

Unless someone can tell me why it's better to propose a change in an issue and then copy the proposal to a PR.

[tonygermano]

I'm not against someone opening an issue first if it seems warranted. I'm just against it as a requirement, because the PR is the thing that needs to be reviewed and get approval, not the issue.

[ssrowe]

Given that this is governance, I think having the issue makes sense for a notice period so everyone is aware of a pending change. Then the PR is simply the execution of the decision. We can easily backtrack issues for PRs that get opened prematurely.

[ssrowe]

@tonygermano I agree with your points for code. But for governance, I see benefit in having the details in both places. A PR will be necessary to make the change, but I think it’s a good idea to start the conversation for governance changes in an issue and then move to a PR.

[tonygermano]

Thank you for replying @ssrowe. I guess my line of thought is that a PR is just an issue with a proposed resolution rather than an issue without an immediate solution. I don't see the need to double up just for the sake of always having both.

In the github api, a PR is an issue with a special flag. You can assign labels to PRs and assign PRs to Milestones and Projects just like regular issues. It's a lot easier to comment and request changes on a PR than it is in an issue because you can read the full proposal rather than a summary or paraphrases, comment on specific lines, and optionally require resolution on the comments. You can close a PR without merging just as easily as you can close an issue with "won't fix" if the changes don't pass after revisions.

It seems like we have the mentality right now that if a PR is opened it must be accepted, but that doesn't have to be the case. PRs can be a place for ideas, too. I also don't know how you have a 14-day review period in an issue or how you measure approval in an issue, since a PR is the place to "vote," and we already decided after OpenIntegrationEngine/engine#13 that an Issue is a poor way to gather votes.

You mentioned you can see a benefit in having both. Can you articulate that benefit? That's the part I'm missing, as it just seems like busy work to me.

Edit: Just wanted to add that a PR in draft mode can be a very useful tool for discussion.