[RFC] Rust-embedded-community as child organization

[eldruin]

Detailed terms to mark the rust-embedded-community as a child/sub organization.
Feedback is welcome.

Rendered

Related: rust-embedded-community/meta#3, rust-embedded-community/meta#7

[ryankurte]

i do not think i understand what is meant by child/sub organisation in the context of this RFC?

[eldruin]

i do not think i understand what is meant by child/sub organisation in the context of this RFC?

The REC org would officially be a subproject of the REWG. Does that make it clearer?

[ryankurte]

so what are the expected changes from the RFC? are we talking about adding some links, moving REC projects / teams under the rust-embedded org, or maintaining the separate org as an EWG project? also would we have an EWG REC team? (and would this be EWG REC maintainers, or all REC members?)

[eldruin]

The REC would continue to be a separate org but it would officially be an EWG project (similar to the EWG being an official "sub org" of the rust-lang org, if you wish).

I proposed having a small REC/governance team filled with members from the EWG and that's it (similar to the EWG core team). Otherwise REC membership is separate from EWG and should include more community members and define its own teams.

Boiled down, the changes for the EWG are:

• link (as in <a href=...>) to REC.
• a group of EWG people form a governance team inside the REC.

[nikomatsakis]

I've not had time to read the RFC yet, but I want to add a note that the @rust-lang/core team would like to weigh in on this a bit too. This kind of touches on a larger question of how to approach the hosting of projects, which has sometimes been a source of controversy in the past. In particular, hosting projects can create the perception (intended or unintended) that the crate is "blessed' and to be preferred to the alternatives, which in turn can create controversy.

Anyway, this is on the core team agenda, and I've added to my personal to do list to read the RFC and thread, but in particular we'd like to be consulted before any final decision is made. ❤️

[nikomatsakis]

OK, so, I read the RFC now. I guess it's fair to say that the vision is that rust-embedded-community is seen as serving a few different purposes. It seems like kind of a "playground" for crates that are still experimental or early in their development. The motivation section mentions two distinct (but perhaps overlapping) reasons for a crate to be part of the "community":

• maturity segmentation -- basically a places for things to being their life before their fate is truly known. These might be projects that aspire to become foundational and canonical but which have not yet been proven. Those projects that are truly recommended for folks to use move into the rust-embedded domain proper, but things in the community domain are not there yet. These might also begin as efforts to consolidate an area where a number of "user domain" crates exist (e.g., accelerometer crate rust-embedded-community/meta#5).
• home for unmaintained projects -- a place that people can send things they don't have time to maintain.

Of these, I think that the maturity segmentation is obviously the one with greater risk in terms of people feeling like things are "officially blessed", even if they're not meant to be. I guess one question I have is whether the plan is ultimately for crates like that to move to the rust-embedded WG once they're "vetted"? Or do you think crates would potentially live on in the community area indefinitely?

I guess that one thing which might be useful is writing out some of the criteria that you think would be useful to decide

• which projects to accept in the community (particularly which unmaintained projects)
• when it makes sense to move a crate into the rust-embedded group -- and whose decision is that? presumably it's a joint decision by the rust-embedded group and the rust-embedded-community?

I'm not sure whether those criteria have to be part of the RFC or whether they're something that would evolve over time, but I imagine these are the two major decisions that will have to be made and so it'd be helpful to think about how you'll go about making them.

[nikomatsakis]

OK, I read over the changes. They make sense to me. If I may summarize:

• The "community" will serve to both take on maintenance for existing libraries that need a maintainer and as a incubator for libraries that may eventually come to be adopted by the wider rust-embedded working group.
• To get adopted by the wider group requires agreement both from the maintainers but of course the rust-embedded working group, per the considerations described in RFC 0136.

I will summarize to the core team in our Wednesday meeting and get their feedback, this just represents my immediate reaction. Let me know if anything in the above sounds wrong or incomplete!

[nikomatsakis]

Some random thoughts, not necessarily for inclusion in this RFC:

• I think there might be some value in having a template that makes clear the state of each library and whether it's viewed as an "incubation candidate" or something else.
• If there are other crates, it'd be a good idea to go "above and beyond" in terms of acknowledging them. For example, I think README files should definitely cite other crates and provide meaningful (but friendly) comparisons. This seems particularly true when the crate is trying to unify existing crates into a single crate.
• Finally encouraging authors of other crates to provide feedback or participation (they don't necessarily have to agree with the crate maintainers)

Another question:

Presumably each crate will have its own set of maintainers as well? (I don't recall what the RFC text wrote about this point.) In the case of a controversy, who makes the ultimate decision? I imagine that the rust-embedded-community maintainers has the ability to override if necessary or resolve disputes (and is itself subject to the Rust org structure, ultimately).

[eldruin]

@nikomatsakis has reported that although this has not been officially decided yet, the Rust core team member opinions are that it would be better to keep REC as a separate organization at least for now.
@aidanhs will provide some more background reasoning here.

[eldruin]

Here is the response from @aidanhs:

Hi, thanks for your patience! We had a look at this and discussed within the core team - right now, we think it’d be better placed as an unofficial group unless it becomes clear that being official will help both the rust organisation and community.

To elaborate a little on our thinking:

• given core team focuses at the moment, we want to limit ourselves to considering teams where impact is overwhelming and 'obvious'
• we’d prefer not to have official teams accumulating repositories (given confusion this can cause if efforts dwindle)
• we could imagine multiple independent 'trust groups' of co-maintainers being formed - no reason for only one!

As a result, we think using the trademark (and current name) is too confusing - but we do think it's pretty cool that you're all finding ways to build a community around this, and look forward to seeing how you get on!

So I am closing this RFC and we will follow up on this at the original issue rust-embedded-community/meta#3
Thanks everybody!