Salt Project maintenance policies¶

Issue management¶

Issues for the Salt Project are critical to Salt community communication and to find and resolve issues in the Salt Project. As such, the issue tracker needs to be kept clean and current to the currently supported releases of Salt. They also need to be free of feature requests, arguments, and trolling.

We have decided to update our issue policy to be similar to RedHat community project policies.

Community members who repeatedly violate these policies are subject to bans.

1. All issues that were not opened against a currently supported release of Salt will be closed.

   • When an old release of Salt is marked out of support, all issues opened against the now defunct release will be closed.

   • If the issue is still present in the current release of Salt, submit a new issue. Do not re-open the old issue after it has been closed.

   • When opening a new issue that was a bug in a previous release of Salt, you must validate it against a currently supported release of Salt for consideration. Issues that do not show the problem against a current release will be closed without consideration.

2. Only defects can be submitted to the issue tracker.

   • Feature requests without a PR will be immediately closed.

   • Feature requests must be designated as a feature being developed and owned by the issue submitter and assigned to a release. Otherwise they will be immediately closed.

   • Discussions about features can be held in the GitHub Discussions tab or in the community Open Hour.

   • Questions will be immediately closed.

3. Issues must submit sufficient information.

   • Issues must follow the relevant template for information.

   • Issues that do not give sufficient information about the nature of the issue and how to reproduce the issue will be immediately closed.

   • Issues that do not comply will be immediately closed.

Pull request management¶

The Salt pull request (PR) queue has been a challenge to maintain for the entire life of the project. This is in large part due to the incredibly active and vibrant community around Salt.

Unfortunately, it has proven to be too much for the core team and the greater Salt community to manage. As such, we deem it necessary to make fundamental changes to how we manage the PR queue:

1. All PRs opened against releases of Salt that are no longer supported will be closed immediately.

2. Closed PRs can be resubmitted, NOT re-opened.

3. PRs need to provide full tests for all of the code affected, regardless of whether the PR author wrote the code affected.

4. PR tests need to be written using the current test mechanism (pytest).

5. PRs need to pass tests.

6. PRs must NOT increase the overall test time by a noticeable length.

7. PRs must NOT add new plugins directly to Salt unless sanctioned by the Salt core team. New plugins should be made into Salt Extensions.

8. PRs that have not been updated due to inactivity will be closed. Inactivity is determined by a lack of submitter activity for the space of 1 month.

9. PR tests should always maintain or increase total code coverage.

Salt Enhancement Proposals (SEP) process¶

A message from Thomas Hatch, creator of Salt:

In 2019, we decided to create a community process to discuss and review Salt Enhancement Proposals (SEPs). Unfortunately, I feel that this process has not proven to be an effective way to solve the core issues around Salt Enhancements. Overall, the Salt enhancement process has proven itself to be more of a burden than an accelerant to Salt stability, security, and progress. As such, I feel that the current optimal course of action is to shut the process down.

Instead of the Salt Enhancement Proposal process, we will add a time in the Open Hour for people to present ideas and concepts to better understand if they are worth their effort to develop. Extensive documentation around more intrusive or involved enhancements should be included in pull requests (PRs). Conversations about enhancements can also be held in the Discussions tab in GitHub.

By migrating the conversation into the PR process, we ensure that we are only reviewing viable proposals instead of being burdened with requests that the core team is expected to fulfill.

Effective immediately (January 2024), we are archiving and freezing the SEP repo.