ECS RFC process questions

The RFC process includes at least one step that I'm not sure how to participate in, highlighted here:

  1. Create a new RFC document from the RFC template (described below)
  2. Fill in the details for your strawperson
  3. Open a PR to commit your RFC to rfcs/
  4. ECS committee and/or team members review
  5. ECS committee and/or team member merges RFC, formally accepting the strawperson
  6. Expand existing RFC document with additional details
  7. Open a PR to commit your proposed changes to the RFC and advance to stage 1
  8. ECS committee and/or team members review
  9. ECS committee and/or team member merges RFC, formally accepting the proposal
  10. Repeat steps 6-9 for stages 2 and 3

I think this is meant to be a phase that involves community discussion in order to best advance the design? (Or is it really just "ECS committee" -- this isn't defined in the RFC doc? -- and elasticians?) If it's to get community involvement, maybe the method for that could be made explicit? Otherwise the community might go rooting around forums, Slack, issue comments, etc. to look for it, which might be more friction than some can endure?

And to be a little clearer, when I say "in order to best advance the design" I'm talking about things like:

  • crowdsourcing knowledge/expertise/motivation
  • avoiding orphaned schema development work

Not all steps will be required for all RFCs. If a proposal already contains sufficient detail to address all the necessary criteria, earlier stages of the process can be skipped.

At the strawperson stage, RFCs can be quite high-level and maybe as simple as a few sentences demonstrating a need for a concept to be captured in ECS. Later stages expect the author(s) to further flesh out the high-level idea in more detail (the RFC template contains comments to help the author with what type of detail is expected for each stage: ecs/rfcs/0000-rfc-template.md at main · elastic/ecs · GitHub).

Thanks for chiming in, Eric. This is helping me get a better understanding.

The specific thing I'm wondering is can we get larger community involvement in RFCs going through development?

For example, a strawman RFC was submitted for RPC, but has not moved in three years.

Heaven forfend, but if @axw were run over by a Coopers delivery truck, how would the larger community interested in having RPC information in ECS get what they need? So maybe an explicit "if you find languishing RFCs clogging progress for your desired schema updates, please do submit a new RFC" could work?

But part of what I think would be useful for ECS development is to make clear to the larger community who are interested in specific schema subsets that there is a process by which folks can discuss and advocate around a given subset. This would allow injection of experience from interested parties and other benefits as mentioned.

It could be I've missed a clear message somewhere that explains where the community can discuss a particular RFC, or maybe it's obvious where such discussion would happen and I just failed to figure it out.

The donation of ECS to OpenTelemetry will greatly help, and most of the new schema development will happen through contribution to OTel Semantic Conventions. There's an open ECS PR documenting this expectation, if you have any feedback on how we document this for the ECS project.

For example, a strawman RFC was submitted for RPC , but has not moved in three years.

RFCs rely on contributors to advance their proposals. If the original author(s) don't move the proposal forward or other interested contributors continue the work, it's possible for a proposal to stall.

RFCs can be marked as Stage X if a proposal isn't moving forward in the near term (but still could advance in the future), so IMO the RPC should be updated to Stage X.