Amethyst has had a lot of turn over since the current design was conceived. There have been many great things contributed, and, as with all big projects, many lessons to reflect on. This proposal is the sum of my reflections from my time as a member of the Amethyst community.
The proposal can be broken into two parts:
Restructure the teams for more balanced exposure to internals and to create stronger support for development.
Refactor the product to have the bare essentials in a singular crate, not a wrapper, that provides the minimal for 2D or 3D development. Discussed in a separate topic here: Amethyst internals restructuring.
1. Discard notions of specialized teams, ie “Networking Team”
A game engine is a very complicated thing, and it makes sense to collaborate in a way that pools around individual components. This can work in corporate settings decently well. However, we don’t have the support of a corporation; there are no guarantees we will always have someone with a given specialization. With no one left on the current Networking Team (save Fletcher), who has the intimate knowledge with the internals to get things done?
2. Structure into four teams: Core, Ecosystem, Experience, and Oversight
Not to be confused with the Rust Core Team, this would consist of people who work on
amethyst itself, as well as official utilities.
A much larger group than Core, this team would be anyone that maintains Amethyst crates that aren’t part of
amethyst itself. Projects that join the Amethyst umbrella would be subteams. The goal of the team as a whole would be to fill in the gaps that the new
amethyst crate leaves behind. Experimentation inside this team would be welcomed.
In short, any labor that isn’t contributing code would fall under Experience. In addition to an infra subteam, this team would do documentation, community management, website/branding, and general public relations.
I’m eager for name alternatives, but this team would be the OSS equivalent of administration. Lead by the Board of Directors, this team would handle the finances, inter-community/organization outreach, and other logistical matters. More importantly, this team would also be responsible for ensuring a minimum amount of coordination between teams, while not taking on full Project Manager responsibilities.
3. Scale the bar for membership tiers - Lower for lower, higher for higher
- Trusted Contributors would be more of a community status. It would be less privileged, and more freely given.
- Create checklists for each tier of membership, to evaluate promotion and demotion
- This is highly necessary to ensure fair and consistent rewarding of contributions to the engine and community.
- Move “org membership” perks into a separate status independent from TC vs Team Member vs Board, for contributors who have stayed with us for a long while.
- Perks being defined as more consequential benefits, such as GSuite accounts.
Please share any and all thoughts. I didn’t include all of my thinking for many of the points, so please ask me to elaborate on anything.