docs: contribution: tracking issues and pull requests#162
docs: contribution: tracking issues and pull requests#162JGBSouza wants to merge 2 commits intokworkflow:unstablefrom
Conversation
JGBSouza
changed the title
lorenzoberts
left a comment
lorenzoberts
left a comment
There was a problem hiding this comment.
Hey @JGBSouza, thanks for the proactivity of creating the issue and addressing it. Let me know what you think about my comments. Besides that if you can address the commit messages changes considering what i've said in the other PR, it would be awesome.
CONTRIBUTING.md
Outdated
| Every Pull Request must reference the issue it addresses (e.g., Closes #123 or Resolves #123). If no issue exists, please create one before opening the PR. | ||
|
|
||
| This practice improves project organization and traceability, allows maintainers and contributors to judge the necessity of a change before implementation, and | ||
| enables GitHub’s automatic linking between issues and PRs. This makes it clear to everyone that work is already in progress, avoiding duplicated effort—even if |
There was a problem hiding this comment.
| enables GitHub’s automatic linking between issues and PRs. This makes it clear to everyone that work is already in progress, avoiding duplicated effort—even if | |
| enables GitHub’s automatic linking between issues and PRs. This makes it clear to everyone that work is already in progress, avoiding duplicated effort — even if |
CONTRIBUTING.md
Outdated
|
|
||
| **Note**: PRs should always be opened using the branch `unstable` as a base. | ||
|
|
||
| ### Pull Requests Tracking |
There was a problem hiding this comment.
shouldn't this be "Issue tracking"?
CONTRIBUTING.md
Outdated
|
|
||
| ### Pull Requests Tracking | ||
|
|
||
| Every Pull Request must reference the issue it addresses (e.g., Closes #123 or Resolves #123). If no issue exists, please create one before opening the PR. |
There was a problem hiding this comment.
I understand the importance of this, but i'm not sure if this should be mandatory for all pull requests. Bug solving and feature request make total sense to have a tracked issue, but i'm not sure if general improvements/refactors, test coverage and some minor changes also do.
I'm open to discussions, but in my opinion we can be slightly more flexible about this. Also, nothing stops us of creating the issue after the PR is opened, if we evaluate that it should be tracked. I understand the "risk", which would be duplicated effort, but we also need to assess the project current development context, which doesn't consist of so many contributors. My fear with a strict guideline is discourage new contributors due to another extra requirement before contributing.
There was a problem hiding this comment.
I agree, the project can be more flexible about this, but i still think that reformulating this paragraph it as a tip can be a good thing for the project, even if there are not many peoples working on it, guiding the efforts of the new contributors can be a good thing, even adressing previous discussions and abandoned pull requests can be usefull. If you agree with this i could rewrite this section so it fits better
There was a problem hiding this comment.
@JGBSouza yes, i agree. If you could rewrite it to a slightly more flexible version, maybe more close to a recommendation than to a obligation, it would be perfect
JGBSouza
force-pushed
the
docs/tracking_issues_and_pull_requests
branch
2 times, most recently
from
1a61983 to
9d33c93
Compare
|
@lorenzoberts, updated this pr and fixed the conflicts! |
As we are working on a free software environment, managing issues and contribution is a hard task, most of the times, there may have some pull requests closing some issue that haven't been revewed, and as it's not the most common approach search in a long list of pull requests if an issue is still on hold, there may be cases when other contributors may start to work on a problem that could be already solved. In this sense, this commit add a new section suggesting that the users should mention the issue related to the pull requests in the commentary, so github will automatically notify the issue that there is a pull request on hold for that, avoiding double work around it. Signed-off-by: JGBSouza <joaosouzaaa12@usp.br>
Tracking implementations as issues in github may be very usefull for a free software context, as it can give more visibility of what is on development and let the others be able to discuss an implementation even before it starts, making it less likely that there will be an effort on developing a solution that will not be needed. In this sense add a few more context on issue tracking section, stating the need to always open a issue when there is no issue created for a future development. Signed-off-by: JGBSouza <joaosouzaaa12@usp.br>
JGBSouza
force-pushed
the
docs/tracking_issues_and_pull_requests
branch
from
9d33c93 to
2770914
Compare
|
hey @JGBSouza, thanks for the modifications. I just reworded the commit messages a little. Merging the PR into unstable. |
2 participants
Highlight that every bug or feature should be tracked as an issue in the github.
Guide contributors to create a new issue before starting to implement the PR resolves it.
Pull Request Guidelines:
Instruct that every PR must reference the corresponding issue (e.g., “Resolves/Closes #'161”).
#Solves #161