Feature Proposal Procedure #51
Conversation
proposals/README.md
Outdated
| 2. The proposer creates a GitHub pull request that adds the document to the proposal directory in a subdirectory named for the year in which the submission is being made (e.g. proposals/2018/Add_New_Feature_XYZ.md). | ||
| 3. The proposer, the BuildingSync team, and other stakeholders and interested parties discuss the proposal and make modifications using the GitHub pull request discussion facility. At the conclusion of this process, the proposal is accepted or rejected. | ||
| 4. If the proposal is accepted, it is merged and the appropriate GitHub tracking procedure (issue, project, etc.) is initiated to track progress toward completion. | ||
| 5. The change is made by the appropriate developer (not necessarily the proposer or a BuildingSync team member) following the contribution policy. |
There was a problem hiding this comment.
@fieldkm Ideally, a lot of the time it would be the proposer. But I can think of cases where it would need to be someone else (lack of availability, etc.). I guess in cases where it would not be the proposer doing the changes, the "who" should be decided in an earlier step. I could include "identification of the appropriate developer" as part of item 4, before merging. How about:
- If the proposal is accepted, a developer is identified (not necessarily the proposer or a BuildingSync team member) and the pull request is merged. The appropriate GitHub tracking procedure (issue, project, etc.) is initiated to track progress toward completion.
I know that leaves the "how" a little murky, but I think that's OK in this case if selection is required before the proposal is finally accepted.
There was a problem hiding this comment.
I agree - this is a good compromise. It probably wouldn't work well to anticipate every possible appropriate developer anyway. Your solution here looks good to me.
proposals/README.md
Outdated
|
|
||
| 1. The proposer writes a Markdown document, modeled on this document, that succinctly describes the changes that are proposed. | ||
| 2. The proposer creates a GitHub pull request that adds the document to the proposal directory in a subdirectory named for the year in which the submission is being made (e.g. proposals/2018/Add_New_Feature_XYZ.md). | ||
| 3. The proposer, the BuildingSync team, and other stakeholders and interested parties discuss the proposal and make modifications using the GitHub pull request discussion facility. At the conclusion of this process, the proposal is accepted or rejected. |
There was a problem hiding this comment.
who decides on the final "accepted/rejected" criteria? Is it a vote?
There was a problem hiding this comment.
@nllong I guess so, but maybe with the project lead making the final call if there isn't a clear consensus. How about adding this additional sentence:
If a clear consensus cannot be reached to accept or reject the proposal, the project lead will decide if the proposal should be accepted.
There was a problem hiding this comment.
sounds good. Just wanted to make sure that it was clear. "If a clear consensus cannot be reached to accept or reject the proposal, the project lead will decide if the proposal should be accepted." makes sense. Were you planning on adding that text? (Or maybe I missed it).
There was a problem hiding this comment.
@nllong Adding the text now.
proposals/README.md
Outdated
| 1. The proposer writes a Markdown document, modeled on this document, that succinctly describes the changes that are proposed. | ||
| 2. The proposer creates a GitHub pull request that adds the document to the proposal directory in a subdirectory named for the year in which the submission is being made (e.g. proposals/2018/Add_New_Feature_XYZ.md). | ||
| 3. The proposer, the BuildingSync team, and other stakeholders and interested parties discuss the proposal and make modifications using the GitHub pull request discussion facility. At the conclusion of this process, the proposal is accepted or rejected. | ||
| 4. If the proposal is accepted, a developer is identified (not necessarily the proposer or a BuildingSync team member) and the pull request is merged. The appropriate GitHub tracking procedure (issue, project, etc.) is initiated to track progress toward completion (e.g. a GitHub issue assigned to the developer). |
There was a problem hiding this comment.
If the proposal is accepted, new GitHub issues are created to track the development (or a GitHub Project if it is a larger proposal), and a developer is assigned to the issues (not necessarily the proposer or a BuildingSync team member). The "proposal" pull request is merged."
|
@nllong I've made a few additional changes (e.g. adding project lead decision to the acceptance of implementation). One thing we haven't specified is PR reviewer. Should we do that as well? |
Add a document describing how changes and new features are proposed and integrated into the repo. Addresses part of #47.