2018-05-02 23:00:31 -03:00
|
|
|
# Contributing
|
|
|
|
|
|
2022-11-11 00:10:00 +01:00
|
|
|
Thank you for considering contributing to Settings!
|
|
|
|
|
|
|
|
|
|
All code contributions are made using merge requests.
|
2018-05-02 23:00:31 -03:00
|
|
|
|
|
|
|
|
Please note we have a Code of Conduct, please follow it in all your interactions with the project.
|
|
|
|
|
|
2022-11-11 00:10:00 +01:00
|
|
|
## Creating Merge Requests
|
|
|
|
|
|
|
|
|
|
To open a merge request fork the Settings project, and then create a branch for your change.
|
|
|
|
|
When the change is ready, submit a merge request.
|
|
|
|
|
|
|
|
|
|
The following guidelines will help your change be successfully merged:
|
|
|
|
|
|
|
|
|
|
* Keep the change as small as possible. If you can split it into multiple merge requests please do
|
|
|
|
|
so.
|
|
|
|
|
* Use multiple commits. This makes is easier to review and helps to diagnose bugs in the future.
|
|
|
|
|
* Use clear commit messages (see below).
|
|
|
|
|
* Attach screenshots of the change.
|
|
|
|
|
* Link to relevant issues this change is related to.
|
|
|
|
|
* Always set the merge request to allow maintainer edits - this makes it easier
|
|
|
|
|
for a maintainer to make small improvements to land the change faster.
|
|
|
|
|
|
|
|
|
|
Please format commit messages as follows:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
component: <summary>
|
|
|
|
|
|
|
|
|
|
A paragraph explaining the problem and its context.
|
|
|
|
|
|
|
|
|
|
Another one explaining how you solved that.
|
|
|
|
|
|
|
|
|
|
<link to issue(s) this change fixes>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## Bug Fixes
|
|
|
|
|
|
|
|
|
|
Changes that fix bugs include:
|
|
|
|
|
|
|
|
|
|
* Correcting code that crashes.
|
|
|
|
|
* Spelling mistakes in labels.
|
|
|
|
|
* Small layout issues (e.g. spacing).
|
|
|
|
|
* Use of deprecated APIs.
|
|
|
|
|
* Restructuring of code for improved safety.
|
|
|
|
|
|
|
|
|
|
Please include clear information in the commit message(s) and merge request that indicate what is
|
|
|
|
|
being fixed by the change.
|
|
|
|
|
|
|
|
|
|
These changes will be reviewed for correctness, and then merged once this is complete.
|
|
|
|
|
|
|
|
|
|
## User Experience Changes
|
|
|
|
|
|
|
|
|
|
Changes that impact the user experience of Settings require approval from the
|
|
|
|
|
[Design Team][design-team]. This includes:
|
|
|
|
|
|
|
|
|
|
* Addition or removal of features in existing panels.
|
|
|
|
|
* Changes to the layout of panels.
|
|
|
|
|
* New panels.
|
|
|
|
|
|
|
|
|
|
Please include before/after screenshots in the merge request to show what is being changed.
|
|
|
|
|
|
|
|
|
|
For one of these changes to be merged one of the following is required:
|
|
|
|
|
|
|
|
|
|
* The change is shown in an existing mockup done by the design team (linked to in the merge request
|
|
|
|
|
or issue).
|
|
|
|
|
* A comment from a design team member in the merge request or issue approving the change.
|
|
|
|
|
|
|
|
|
|
If a merge request is opened without the above the "Needs Design" label attached to it and will not
|
|
|
|
|
be merged until design approval is received.
|
|
|
|
|
|
|
|
|
|
Once design approval is obtained, the change will be reviewed for correctness, and then merged once
|
|
|
|
|
this is complete.
|
|
|
|
|
If design approval is not obtained, the merge request will be closed.
|
|
|
|
|
|
|
|
|
|
[design-team]: https://gitlab.gnome.org/Teams/Design
|
|
|
|
|
|
|
|
|
|
## Reviews
|
|
|
|
|
|
|
|
|
|
All changes require approval from one or more Settings maintainers.
|
|
|
|
|
Reviews are likely to ask for changes to be made, please respond to these as soon as you are able
|
|
|
|
|
and ask for clarification if the requests are not clear.
|
|
|
|
|
|
|
|
|
|
When the change is ready to land a maintainer will mark it as approved.
|
|
|
|
|
Then the change can be merged by either a maintainer or the submitter if they have suitable
|
|
|
|
|
permissions.
|
|
|
|
|
|
|
|
|
|
## Draft Merge Requests
|
|
|
|
|
|
|
|
|
|
Merge requests marked as draft will not be reviewed by Settings maintainers or merged.
|
|
|
|
|
When the change is ready for review please mark the merge request as ready.
|
|
|
|
|
|
|
|
|
|
## Inactive Merge Requests
|
|
|
|
|
|
|
|
|
|
If a merge request has comments from maintainers that have not been responded to within 4 weeks this
|
|
|
|
|
merge request is considered to be inactive and will be closed. The reporter may re-open it at a
|
|
|
|
|
later date if they respond to the comments.
|
