Migrate RFC repo

[iredelmeier]

Can we please migrate the RFC repository (originally proposed in #56) so that we can start using it, now that the first spec milestone is finished?

An admin setting is currently blocking me from requesting that the repo be transferred.

[bogdandrutu]

QQ: do we want the rfcs to be part of the specification repository as a different directory or a separate repo?

[bogdandrutu]

I can help with migration but want to know which approach we want to go: separate repo vs separate directory in specification

[iredelmeier]

I suggest separate repo.

[iredelmeier]

@bogdandrutu I also don't mind transferring the repo to you (or another admin) first, if that makes the most sense with respect to the org policy not allowing non-admins to create or transfer repos.

[bogdandrutu]

I think you just need to add me as Admin for your repo in order to move it. But I am trying to get an agreement from others that a separate repo is the right decision here.

[iredelmeier]

Invite sent!

The question has come up a few times, but I haven't heard anyone actually suggest that the RFCs should be in the spec repo.

Some (definitely forgetting some! only halfway through my coffee...) advantages I see of keeping it separate:

• Separation of concerns: having separate repos lets us keep issues and PRs independent, so that triage and searchability are easy without us having to jump through any hoops
• Lets us more easily support different SLAs (à la Draft starter SLA for issues and PRs #129) for RFCs vs specs, since they'll almost definitely need different requirements
• More inclusive of cross-cutting concerns and other SIGs

Frankly, I've seen a high correlation (which is not to say causation!) between RFC process success and keeping the RFCs independent of the specs and other repos.

[iredelmeier]

Argh, since the repo is only owned by an individual rather an org, I can't actually make you an admin. See #131 🤷‍♀️

[bogdandrutu]

I can clone and move, or we can create a clean repo and you do move all the commits.

[iredelmeier]

Mind if we do an actual transfer so we don't break redirects for clones, links, etc? (i.e., by me transferring the repo to you)

Worked around it by transferring the repo to the LightStep org in order to make an admin.

[SergeyKanzhelev]

great! Let's do it. I'd suggest to start with empty submit docs as a PRs. It will give a chance to comment

[iredelmeier]

@SergeyKanzhelev what do you mean by "empty submit docs"?

[SergeyKanzhelev]

I meant start with empty repo and submit docs as PRs.

[SergeyKanzhelev]

Docs looks ok in general though. So just want to make sure there is a forum for discussion and commenting

[iredelmeier]

@SergeyKanzhelev https://github.com/lightstep/rfcs#changes-to-the-rfc-process

[bhs]

Misc: while it's on my mind, I just wanted to drop in a quick (enthusiastic) note regarding the idea of the RFC repo in general: it seems nearly impossible to have a substantive debate about "big" GitHub issues that make several substantial points "in parallel"... everything gets lost in > blocks. Whereas with an RFC PR, it's possible to have little sub-threads about individual aspects of the RFC, and also to get piecemeal consensus about the RFC. For a GitHub issue, it's "all or nothing" and that can be a recipe for frustration (e.g., open-telemetry/opentelemetry-go#19).

[bogdandrutu]

@bhs nobody in this thread disagrees with the benefit of having a RFC process, the only question that I had was if this should be part of the specification or a separate repo.

The second question that came during this discussion is about the process of transferring a repo with new work (like this) vs constructing it in the org. More explicitly in the current case should we create a new repo and @iredelmeier will create a PR that copies the content from the previous repo or we do a move.

[bhs]

nobody in this thread disagrees with the benefit of having a RFC process

🆒, that is good to hear!

[bogdandrutu]

@bhs can you try to answer some of my questions? I talked with @SergeyKanzhelev and seems to want a separate repo as well as @iredelmeier. So I am fine with this but I want to hear your opinion as well.

Also will be good to have your thoughts on the second question - @SergeyKanzhelev mentioned the path to create a clean repo and do a PR that copies the code. What do you think about this?

[bogdandrutu]

I am trying to not block this, but find the right path forward.

[bhs]

@bogdandrutu

I talked with @SergeyKanzhelev and seems to want a separate repo as well as @iredelmeier. So I am fine with this but I want to hear your opinion as well.

I do not have a strong opinion about this. If it was literally up to me, I would put the RFCs into the https://github.com/open-telemetry/opentelemetry-specification repo (in a /RFCs/ subdir or similar), but bottom-line I am equally happy citing prior art in Rust or k8s or whatever and copying whatever arrangement they've been using.

The second question that came during this discussion is about the process of transferring a repo with new work (like this) vs constructing it in the org. More explicitly in the current case should we create a new repo and @iredelmeier will create a PR that copies the content from the previous repo or we do a move.

I do not understand the details of how CLAs work with things like these. For the particular case of the RFCs, I would probably vote to have @iredelmeier create a PR that copies the (relatively small amount of) content over in one fell swoop, but I would have a different opinion about transferring a repo that had years worth of commit/PR history in it. This is not a strongly-held opinion of mine and should be considered "non-blocking."

I am trying to not block this, but find the right path forward.

Totally! And a worthwhile (and appreciated) thing to do given that we'll all be living this for a long time to come.

[iredelmeier]

I do not understand the details of how CLAs work with things like these. For the particular case of the RFCs, I would probably vote to have @iredelmeier create a PR that copies the (relatively small amount of) content over in one fell swoop, but I would have a different opinion about transferring a repo that had years worth of commit/PR history in it. This is not a strongly-held opinion of mine and should be considered "non-blocking."

@bhs my understanding is that @SergeyKanzhelev's concern here isn't about the CLA, but about reviewing all the changes as an addition vs suggesting changes on top of the base. @SergeyKanzhelev is that accurate?