Showcase Team Tools and Workflow

(Khionu Sybiern) #1

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.

Code style

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 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.

Commit flow

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.

1 Like

Evolution Island and the Showcase Team
(doomy) #2

This all looks great!

For meetings, talking real-time helps everyone realign and stay on task, which is super important. Because we all have different lives that may preclude meeting in voice (work, stress, time differences, social anxiety, etc.) I strongly agree that all meetings should be optional. I love the thought of transcribing our discussion and making sure any notes are shared with the team - so even those who cannot participate real-time can still be included in discussion.

Depending on how quickly we work, perhaps meeting bimonthly or even weekly would be better. However that’s more of a play-by-ear kind of thing.

I also think we should make a point to discuss the way of structuring and managing our workload every time we meet (I think this is along the lines of a “retro” in agile terminology?) to make sure that 1). none of us are getting burnt out and 2). that we’re all working in a sustainable and communicative manner


(Khionu Sybiern) #3

It’s “Agile inspired”, heh. I don’t want to go full Agile (my poor back couldn’t handle it)

What I would like to do is take the burden of managing the Project Tracker for myself, and do less coding. My ideal here is to enable you all to do as much as you can, and the Tracker being more of a reference. I would encourage discussion on it, of course, I just wouldn’t want people to think that this structure is a responsibility for anyone but myself.

1 Like