docs/internal/processes.md
Almost all the development of Slint is done in the https://github.com/slint-ui/slint mono-repository.
There are a few other repositories in the organization, they are either
All the code of the Slint product is in the mono-repository. Having a single mono-repository makes it easier to do changes across the whole product
Different files in the Slint repository have different licenses, and all the license are tracked with REUSE.
The administrators of the slint-ui Github organization are the founders of SixtyFPS GmbH. All employees of SixtyFPS GmbH are members of the organization. External contributors may also be invited to become members of the Github organization.
The development happens in the master branch.
Developers can create a branch <developer-name>/<feature-name> in the slint-ui/slint repository to make a PR, although some developers prefer to work on their own forks.
Only members of the organization can push to a branch in slint-ui/slint, so outside contributors need to create a PR from a branch in their own fork.
For simple commits that do not need to be reviewed and are unlikely to break the CI, the commit can be directly pushed to the master branch without creating a PR.
The master branch is protected, only admins are able to push directly to the master branch.
A PR should be reviewed before being merged, unless the PR is trivial. Trivial PRs may be merged without review.
Reviewers can leave comments on the PR. Some comments are just nitpicks but some other comments should be addressed before merging the PR. Reviewers should make an effort to clearly indicate what needs to be addressed to obtain approval.
Once approved, the author of the PR can merge the PR if he has the rights to do so. For external contribution, the reviewer must merge the PR.
Ideally, the PR should keep a clean history with self contained commits.
If the history of the PR is clean, the PR can be "Rebased and merged" so that the individual commits are merged into the master branch.
But some developers do not take care to keep a clean history and a PR may contain many commits or "autofix" commits.
In this case it is preferable to "Squash and merge" the PR in the Github UI.
The submitter can edit the commit message to make it nicer and removed the artifacts of all the "fixups".
The CI is driven by Github Actions.
The CI is triggered for any PR (including drafts) to the master branch, or to a branch that starts with feature/.
The CI is also triggered for every push to the master branch.
A new commit on a branch will cancel the previous CI run on that branch if it is still running.
There is a nightly build that runs every night.
It will build release artifacts and upload them to the nightly Github release.
And will also generate the docs, wasm build of examples, and publish them on snapshots.slint.dev/master
It will also run a few extra tests (like running cargo update to check for broken dependencies).
New minor releases of Slint are done every couple of months.
The release process is described in <./release.md>
Users are reporting bugs and feature requests on the Github issue tracker.
The process to triage and assign label is documented in the <./triage.md> file.
For long-term planning, we primarily use two processes: Initiatives and Project Boards.
Initiatives describe long-term goals that we as a team want to work towards.
Writing these goals down as an initiative benefits us in several ways:
All Slint Members can propose Initiatives in Outline. Ideally, a proposal should address:
- Approved Initiative is added to the roadmap with info owner/timeline/key results
- Priority is based on urgency, impact, and capacity.
- Owner tracks progress towards key results. Updates shared weekly.
Initiatives are discussed by the team, reworked if necessary, and finally accepted or rejected.
Once an initiative has been accepted, the owner should migrate it to a Github issue. For this, use either the "Tracking Issue" template, or assign the "roadmap" label to an existing issue. Add any corresponding sub-issues if needed.
The issue will be automatically added to the "Team Planning" Board when it receives the "roadmap" label.
We encourage the use of Github Project Boards to organize tasks.
To track long-running tasks, we use a private "Team Planning" Github Project board. When Members of the Slint organization work on long-term goals, they should make sure that they are assigned to a corresponding issue on this board. Maintaining this board allows us to get an overview of who is working on which topics at any given time and to better plan long-term. We check this board during our weekly meeting to see if it is still up-to-date.
Larger initiatives and tasks may also benefit from their own project boards. We leave it up to each individual project owner to decide whether they want to organize their tasks using additional Project boards.