Skip to content

Procedure of How to Suggest New Code #42

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jolly-fellow wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Procedure of How to Suggest New Code #42

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions process/how_to_suggest_new_changes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
## How to Suggest New Code, Documentation, or Other Development Artifacts

#### Context:

Our project management system is driven by issues, which means that it tracks tasks through issues rather than pull requests. To propose a new activity, such as reporting a bug or making changes to the repository, you need to create an issue with a detailed description of what changes you want to make and why they are important. The issue will be discussed at a developer meeting, and if it is deemed necessary, it will be added to a sprint, and a developer will be assigned to work on it.

However, there are cases when you have already made changes to the code or documentation that address the issue you want to create. For example, you may have conducted initiative research, tested your ideas, experimented with the code, made many modifications, and then found a significant improvement that makes the project much faster. Alternatively, while working on another task, you may have discovered and fixed a bug. In these cases, you already have a set of modifications that you want to suggest adding to the repository.
Copy link
Contributor

@stephen-diesel stephen-diesel Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like making something like this an official process may enable contributors to work too much on things that may not have been deemed a priority by the team. We need to discuss this with the broader team but I am less supportive of this method than previous discussions about how to manage PRs without issues assigned in the future.

Copy link

@ScottBailey ScottBailey Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not believe every PR requires an issue. For example, misspelling or minor grammatical changes in code comments can be easily fixed and reviewed without needing the debate that this procedure outlines; however, there is a lot of value in communicating to outside contributors what the process for incorporating their changes into the product is.

Simply creating an issue and waiting for it to be added to a sprint and assigned to you is not a good approach. You want to save your changes somewhere and demonstrate your solution to the team when they will discuss the issue. It would be good to save enough information with the issue to allow another person to resolve this issue if needed. You already have a solution and you want to save it with your issue. In this case, another assignee could use your changes, and other developers could see them and discuss your solution.

#### The Procedure:

1. Create an issue with a comprehensive description of the changes or additions you want to propose for the repository.

2. Create a draft pull request with the changes you want to propose.

3. Link the issue with the draft pull request.

4. Wait for the developers to discuss the issue at a meeting. If they decide that the issue should be processed, it will be added to a sprint, and a developer will be assigned to work on it.

5. After the assignee completes the task and the linked pull request, they should switch the pull request from draft to an active state and request a review.

6. Once the pull request has been reviewed, the assignee should merge it to the repository.

7. After the merge, the pull request and the linked issue will be automatically closed.