New Charter Proposal Discussion

[Lokathor]

This issue is for discussion of changing the charter of the working group.

Background: Many people at the meetings have felt that the charter is too restrictive.

Things that we'd like to adjust (based on the discussion during the Jan 22 meeting):

• There should be crates that we implement ourselves.
• There should be actual crate suggestions of what to use.
• We should generally be able to work to provide solutions, not just gather info and relay messages.

Proposed first course of action:

• List examples of a possible action, then say if we should or shouldn't do it without worry of the current charter, then compare with the current charter. This will help reveal and clarify points of desired change in the charter.

[AlexEne]

I will repeat here the point from another thread, just for context.

The current charter states:

However, 'we can create low-level tooling or libraries_ that are aimed at the healthy growth of the ecosystem and is not meant to be opinionated or favor an engine over another.

Examples

This is meant to avoid: amethyst only libs being made under this org, or ggez-only libs, so things targeted at a single engine ecosystem.

It is also meant to avoid starting a game engine here. This is just not a realistic and achievable goal.

Restrictive or not, even things that were ticking that box were forgotten: spirv rust only ecosystem libs or math lib where nobody could agree on how it should look like or what the needed characteristics are.

Also huge +1 for examples

[aclysma]

I tried to come up with some scenarios with a few variations on them. I'll reply to my own post so that my own opinions won't be interleaved.

Recommendations

1. The workgroup decides a common math crate that everyone can use would be in the community's best interest. The workgroup designs and implements a crate and promotes it as the "official rust gamedev math crate" so that the ecosystem will not be divided across math crates
2. A few people in the workgroup really like using a particular math crate and think it would be helpful to others. They would like to attract more people to use and contribute to it. So they propose that the workgroup includes a link to this crate from somewhere central, such that it appears as a general recommendation by the workgroup.
3. A few people in the workgroup notice that most beginner-friendly libraries are using a particular math crate, and feel that it's the best place for a beginner to start. So they propose that the workgroup includes a link to this crate from somewhere central, such that it appears as a general recommendation by the workgroup.
4. The workgroup maintains a list of all known math crates within little-to-no editorial and in no particular order. (like arewegameyet.rs)
5. De-facto, the community mostly converges on two math crates. They're a bit different from each other. The workgroup creates a document that mentions these two crates. It compares what makes them different (for example, one favors free functions and another favors member functions), and recommends that most people should use one of the two.

Tutorials

1. Several workgroup members enjoy using a particular crate (like ggez or amethyst.) They write a tutorial for using this crate and it is hosted within the workgroup GitHub org.
2. Several workgroup members collaborate on a document that is intended for beginners to get something interactive on the screen quickly. They pick a handful of crates from a variety of sources that are popular among the community, suitable for a beginner, and work well together. This tutorial is owned and maintained within the workgroup GitHub org.
3. A few workgroup members collaborate on a tutorial. It is hosted on someone's blog. The workgroup includes a link to it from arewegameyet.rs and mentions it in the monthly newsletter.

Crate Authorship

1. There is interest among many members of the workgroup to implement a mesh deformation library. Members contribute to it and place it in the workgroup's GitHub organization. It appears to be a product of the workgroup.
2. A few projects spring up that implement mesh deformation. Each of the crates have interesting ideas. They're a bit different, but members of the workgroup notice some commonalities and observe that a couple traits can generalize representations enough to make it easier to use them interchangeably. Members of the workgroup author the crate and put it in the workgroup's GitHub organization. It appears to be a product of the workgroup.
3. A few members of the workgroup decide to collaborate on a mesh deformation library. The ideas are discussed by members of the workgroup in the workgroup's discord and issue tracker (maybe because they'd like to take feedback from other workgroup members who expressed interest in such a crate.) The members author the crate and publish it under their own names. The workgroup doesn't promote this crate any differently from other crates that were not authored by workgroup members.

Crate Ownership

1. A crate within the ecosystem is seen as vital, and many people use it. Members of the workgroup ask the owner to transfer ownership to the workgroup to ensure such an important resource is well-maintained.
2. A crate author wants to pass maintainership responsibilities of their crate to the workgroup because they don't have time to do it anymore, and they don't have anyone in mind to take it on. The workgroup pulls the crate into the GitHub organization so that it doesn't go "unmaintained"
3. A crate author wants to pass maintainership responsibilities. The workgroup helps the author publicize that they'd like to pass ownership via twitter post, a flag on arewegameyet.rs, and mentioning in the monthly newsletter.

Signal Boosting

1. A member of the workgroup writes an article filled with their own opinions. They are well reasoned opinions, but being opinions, some of them are controversial. For example, they compare two audio crates and explain why they prefer one over the other. The workgroup member publishes it somewhere outside the workgroup, and the newsletter links to it. The article does not appear as a product of the workgroup.
2. A company announces that they are looking to hire Rust developers. The individual and company they represent appears reputable to most or all workgroup members. The workgroup retweets the announcement and mentions it in the newsletter.

[aclysma]

These are my own personal takes on the above scenarios.

Recommendations:

1. I think it is healthier that crates be authored by individuals or groups of individuals, not the workgroup. I also think if the community were to mostly converge on a particular math crate, it would be better for that to happen organically based on merit
2. I think it's fine to say "most of the ecosystem is using either X or Y" without mentioning alternatives. I'm uncomfortable with opinion-based promoting that doesn't reflect a general pattern or consensus of the broader community.
3. I think this could be ok if it is worded carefully. "X is a popular choice because ..." is a bit more towards facts. If there are two popular choices, it's best to mention both alternatives.
4. Sounds fine to me
5. As long as the convergence is fairly clear, I think this can be worded in a way that errs towards factual claims. And I think it's not controversial that using popular crates makes it easier to interoperate with the rest of the ecosystem, share code, and get help.

Tutorials:

1. I think it would be more appropriate for such a tutorial to be hosted elsewhere (maybe with the library it is demonstrating.) It's not ideal for the workgroup to be on the hook for maintaining it. I don't see a problem with linking to it as long as it doesn't appear to be a product of the workgroup, and we are willing to link to other similar resources as well.
2. I think "popular among the community, suitable for a beginner, and work well together" is key here. Strictly these are opinions, but they can be supported by facts. If there is any controversy, it's better to have it owned by an individual or group of individuals, and the workgroup can link to it. If another group wants to write a second tutorial with slightly different choices, we can link to that one too. We should be cautious that anything the workgroup takes on to maintain needs to pull its weight since maintaining something like this is an ongoing cost of time. However, this seems important enough that it may be worth ongoing cost. I'm not convinced that there is quite enough convergence to make good choices here, so I'd prefer to leave it up to whoever would do this work. At that point, maybe it's best they publish it themself and we link to it. (Which moves it to case 3).
3. Linking to a helpful resource seems like a helpful thing to do.

Crate Authorship:

1. The individuals working on this can do it separate from the workgroup. I don't think the workgroup should take on long-term maintenance for a crate.
2. I think discussion and collaboration is good here, but I think ideally, the crate would be owned by an individual or several individuals, mostly due to maintenance concerns.
3. I think this is the ideal scenario. Happy to see information be passed around as long as it doesn't completely push out other important activities by this workgroup.

Crate Ownership:

1. Again, I'd be concerned about maintenance burden. If it ever got abandoned, someone could fork it. Potentially we could help organize a continuance plan if a crate author vanished, but I see only harm in trying to do something like that pre-emptively.
2. I think it would be better to help them find an individual or several individuals. I'm not opposed to having a gamedev "Rust Bus" but it should probably be a different GitHub org, even if we did it.
3. Completely comfortable with this, I think it's the ideal outcome.

Signal Boosting

1. I think this is fine as long as it's genuinely useful to a broad audience, clearly authored by an individual, and we are careful to not repeatedly promote a single set of opinions such that other voices are not heard.
2. I think this is ok for now, but we need to be very careful about it.

[17cupsofcoffee]

I pretty much agree with everything @aclysma said in their last comment.

On the topic of creating crates, one thing that I think is interesting to note: while raw-window-handle is probably the best example of a crate being designed by/with the WG, it's not actually owned by the WG - it lives in the rust-windowing organization. I think that's potentially a good direction to go - supporting and guiding the creation of crates, but not neccecarily always having them be 'WG-owned crates'.

[Wodann]

Very good examples, @aclysma. I completely agree with your analysis.

Another topic that has previously come up is reviewing of our ecosystem (issue #46 & PR #63). It ties into the topic of recommendations but seems disparate enough to me. I'll use a similar structure to the one above.

---

Reviews

1. The workgroup maintains a repository of reviewed content. Anyone can create pull requests that need to be approved by a certified workgroup member.
2. The workgroup decides on (evolving) metrics (similar to WIP: Example of ecosystem overview #63) for categories of crates in the gamedev ecosystem (this doesn't have to be done for all categories). These are used to provide more insightful comparisons between crates on arewegameyet.
3. The workgroup decides on recommended guidelines and tools for reviewing crates in the gamedev ecosystem. Anyone can follow these guidelines to review content, but the workgroup doesn't review anything itself.
4. The workgroup stimulates reviewing of crates, but doesn't take an official stance in how this should be done.

[Wodann]

In my opinion, the working group should deal as follows with these scenarios:

1. As @aclysma said, the working group should avoid taking up too much "active" responsibility, so maintaining a curated list of reviews seems like a bad idea.
2. With arewegameyet the working group has a powerful tool to broadcast the state of the gamedev ecosystem. Providing more objective metrics for crates that anyone can implement, seems like a low-threshold way to improve transparency.
3. Setting out clear guidelines for how others can contribute seems like a good "passive" contribution for the working group to help on-board more "active" contributors.
4. I think the working group should take a more proactive role in improving reliability of its ecosystem.

[AlexEne]

These proposals seem ok with me (not sure how they differ from the current state), I am not opposed to rewriting the charter, as long as the foundational library / crate or similar wordings are used.

I am a bit conflicted with the recommandations part. Is the proposal here to modify/enhance the are we game yet space or are you proposing a different thing?

Basically all of us that are members can open and create crates (even experiments). I am supportive of them as long as they fall into the library / foundational crate category (even if experimental). Maybe you can see the theme of me avoiding to be inclusive about building engines or games. At the same time nobody really has time to build anything that big, so maybe it's actually about avoiding announcing games or engines, not building them :D.

You want to contribute to something, feel free to do it. e.g. rust-spirv thing can live here just as happy as anywhere else. Readmes can make it clear about experiment and what's a 1.0. We could even make abase repo with License, Readme, Badges, Github Actions setup included.

What would be nice tho, if we create an experiment or something similar, is for the it to at least build. E.g. I don't think that this is an example of a successful experiment.

[AlexEne]

In case the other wg members don't have objections, @Wodann / @aclysma Are you interested in raising a PR to the current charter to clarify it and make it inclusive of the points above ? We can wait for a few more than just 1 merge approval before merging and it should be fine.

[aclysma]

I personally don't see a problem with the charter as it's written. I agree with you @AlexEne that the given examples don't feel much different from the current state of affairs. The examples I gave were just meant to aid in communication and try to find places where there are differing opinions, since changing the charter was brought up recently.

In the call a few weeks ago I felt from one of the comments a sense of wanting to have real impact and not just be a social club. I definitely empathize with that. However I expect that much of this WG's impact will be in less tangible things than writing code.. and I think that's ok.

Ultimately, the work here is always going to be done by individuals. Should someone want to do something (like go make the most awesomest math crate that ever mathed) they are totally free to do it. They don't need the workgroup's blessing or endorsement. Because of this, I think in practice the charter isn't very limiting. Maybe it means their crate isn't owned by the workgroup org, but I don't really see that as a problem.

It may be worth looking at the responses in the survey to the question "What do you think should be the game-dev working group's priorities for the next 3-6 months?" in the context of this discussion. There are a few things I wouldn't want to do (for example, blessing certain crates) but I think most of the suggestions were good and either directly fall under the charter, or can be pursued by individuals or groups, and we can link to them.

I wasn't on the last call, but it sounded like a suggestion was made to create a roadmap. The discussions there could also feed into this discussion on potentially changing the charter.

[Wodann]

@kabergstrom do you agree with the above? If not, what would you like to see changed and/or clarified in the charter?