Note: the contents of this post are not set in stone. Small details may change. Double asterisks (
**) indicate feedback wanted.
As a Studio, we have less need to worry about OSS contributions. Our planning is public to comment, but effectively our own. We will have our own schedules that we aim for, so we need to work without the assumption that people outside the Studio might contribute. With this, I’m viewing GitHub as less vital to the Showcase Team. At the same time, as a newer Team, we need to establish our own rules for code style, merges, etc.
Git and Project Tracking
PlasticSCM doesn’t have project management (integrations we would need to host ourselves), so for the time being it’s not an option, though I did review it (and I did like it, aside from the one issue). I’ve always been fond of GitLab, and it has everything we could need from it, including CI/CD. We have GitLab Gold, as a NonProfit. The integration of all the features would be a productivity boon, so we’ll be taking advantage of it, with GitHub unidirectional mirroring.
We’ll use rustfmt, of course. For the sake of ensuring consistency, we’ll include a default copy of the configuration in all repos. We can propose tweaks as time goes on.
cargo fmt should be run before each commit.
Further details, ie “never unwrap, use expect instead”, may be defined in a CODE_STYLE.md document.
Codebase Structure Breakdown**
As a general rule (though there will definitely be exceptions), a module should be a specific domain. People working on menus shouldn’t have to do much work outside of menu-specific modules. Don’t be afraid of rewriting code that’s similar to code in other modules. If it’s reasonable to merge utility functions, we can do that in a prerelease review.
Tasks and Release Cycle
Each project will have its own Epics, User Stories, and Tasks. Epics will be generalized objectives, User Stories specific features or functionalities, and Tasks being either impromptu tasks (ie bugs)** or an actionable unit of a User Story. Epics will be decided on in meetings or by forum discussion.**
Dedicated release threads will be used to discuss what goes into each release. Minor releases will be decided by a mix of Epics and User Stories, major releases by a set of Epics. Releases will be labeled by SemVer + Build Number**.
ToDo comments are allowed, but their contents should be stored on the Project Tracker.
WIP changes should be commited to a branch on the main repo. Branch names should use issue/bug/hotfix/feature prefixes as appropriate. We’ll use a master branch plus release tags style flow.
Merge requests should either sit for at least 24 hours OR be approved by three** members. All merges need at least one approval by someone other than the author.
Meetings would be held at least once a month in voice, either on Discord or Google Hangouts. Speaking would not be necessary, as long as you can hear those that are. They would be informal and voluntary. Nothing would be decided, but points may be transcribed to a dedicated thread for people to respond to. If no agenda can be created for a meeting, it may be a strictly social session.
All of these details will be finalized as documents in a meta repo under the Showcase Team’s GitLab group, and copied to each repository when necessary.