A fresh step forward - Proposal for future development and collaboration

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.


:+1: Over organization is going to slow things down and introduce more “administrative” burden instead of help them. Once there are enough of us contributing to different thing it may make sense to split into teams, but that is down the road I think.

I would like some clarification on this, I don’t know exactly what you mean.

I haven’t used Amethyst myself much at all, but I do agree that making things as simple as possible while doing the job sounds good. I think that goes well in line of the direction we are trying to hit with the vision of improving developers’ lives.

I think I like the general approach you’re going towards by moving it to one crate and making the consumption less “intensive” and straight forward.

1 Like

Re coordination:
There will always be times when teams need to communicate but do so less. I’m not 100% clear on how the system could work, but I envision it looking like the Coordinators keeping a pooled set of notes, checking in with various teams now and then, and if there’s an opportunity for encouraging more communicating, the Coordinator suggests talking about whatever, maybe like a need that a UI crate has that the 2D API could be extended to support. What I don’t want is these Coordinators holding individuals to deadlines that they didn’t agree to, or exerting pressure without consent in other ways. While there may be deadlines as we had with the WASM grant, the default should be minimal pressure. We will have many people here who are growing as developers or have a life full of commitments that get in the way. We shouldn’t judge or impose, and should be as supportive as possible as peers.

Re “one crate”, I feel this was a critical mistake in the project structure. Too much divergence and over engineered attempts to stitch it back together.

1 Like

OK, I get it, when I heard “minimum amount of coordination”, I thought we were trying to keep the teams as far apart from each-other, when you meant, in other words, “at least a certain amount of interaction between the teams”, right, but without over-imposing on them.

I definitely agree that pushing people to do stuff they don’t have time for is unacceptable. Life is more important.

1 Like

4 posts were merged into an existing topic: Amethyst internals restructuring

This can work really well when if the Coordinator has some sort of ownership in what they are coordinating. For example, if the Coordinator has decision-making power for setting the direction for the areas they are responsible for (the what ), then they have a bunch of natural incentives to be constantly talking to people (seeing if the current direction is working well, does it need to be changed? getting feedback about what might need to be next, etc.).

I definitely agree. I do want to call out that we can avoid those negative things and still have clear rules for how work should get done. As long as we’re up-front about how things work here, folks will respect fair rules. Let me illustrate a single hypothetical rule as an example:

  • Here at Amethyst, we value shipping code at a steady pace. This is tricky with an all-volunteer remote group of engineers. If you assign yourself to an issue on one of our active projects, we expect you to 1) Write a one-line status update every day you work on the task, and 2) work on it at least once every X days, and 3) complete the task within a reasonable amount of time. If any of these conditions aren’t met, you will be unassigned and we’ll look for someone else to do it. Nothing personal! We just need to keep the project moving forward. You can always come grab another task when you have time again.

That’s a good point. We need to think about these things that will give people a sense of accomplishment for success. Things that will motivate people.

So, I felt it was a big enough topic to flush out on its own, so I’d value your input and help shaping Coordinators on this thread.