OpenTelemetry Sandbox #233
Conversation
text/0233-opentelemetry-sandbox.md
Outdated
|
|
||
| There is a desire, but not an expectation, that projects will be moved from the sandbox as an official SIG or incorporated into an existing SIG. There’s also no expectation that the OpenTelemetry project will provide resources to the sandbox project, like extra GitHub CI minutes or Zoom meeting rooms, although we might evaluate individual requests. | ||
|
|
||
| Projects in the sandbox should leave it within one year, either by being merged into existing SIGs, being accepted as independent SIGs, or by being archived. |
There was a problem hiding this comment.
this directly contradicts the previous paragraph. Even CNCF does not have this "leave in one year"(but it does have annual reviews).
There was a problem hiding this comment.
What I'm trying to convey is that it's OK to experiment and to have failed experiments. So, there's a hope, but not expectation that they will "graduate". I added the following, do you think it's closer to what I mean?
Realistically, we know that experiments might get dropped.
There was a problem hiding this comment.
I think what you want is an annual review with possible outcomes being:
- continue as sandbox for another year
- graduate to official OTEL
- abandon project and archive the repo
- transition to another org if there is a better fit
This is not the same as "should leave within one year", which is often unrealistic, nor has a strong justification.
There was a problem hiding this comment.
The concern I had was in having projects in the sandbox indefinitely, without giving enough motivation to move forward. Annual reviews would solve this, as the project might be folded after one year when there's not enough activity.
There was a problem hiding this comment.
If code is made as part of this organization and is open-source, should we have an official "transition" step here, or just assume that people will fork if they want to continue working on that? Would "transitioning to another org" mean that we'd legally transfer the assets there (name, copyright of the code)? If the project is named "opentelemetry-data-visualizer", are we OK in having another entity own it with this name?
I would keep this off for now, and just let people fork the archived repository.
text/0233-opentelemetry-sandbox.md
Outdated
|
|
||
| A low barrier to entry would be desired for the sandbox. While the process can be refined based on our experience, my initial proposal for the process is the following: | ||
|
|
||
| 1. Proposals should be written following the template below and have one Technical Committee (TC) and/or Governance Committee (GC) sponsor, who will regularly provide the TC and GC information about the state of the project. |
There was a problem hiding this comment.
- two people is not a low barrier, what is the motivation?
- "who will regularly provide" - hard no from me
There was a problem hiding this comment.
two people is not a low barrier, what is the motivation?
Combined, the TC and GC group has 16 members if I'm counting right, but you are right. We can have a lower number now and increase if needed. Originally, I didn't have sponsors being on the hook for providing updates, so, a simple "that's nice" would be sufficient from two sponsors. But now that there's an expectation that the sponsor will provide quarterly feedback, the barrier is already higher than 2 simple "that's nice".
"who will regularly provide" - hard no from me
I'll remove this from here, as I define the frequency elsewhere. Is once a quarter acceptable?
There was a problem hiding this comment.
I am opposed to any framework where it is GC/TC responsibility. When OTEL prepares for annual review with CNCF, it's on OTEL project to prepare an update, not on CNCF TOC member. But there is a well-define questionnaire that a project is supposed to answer in the review.
There was a problem hiding this comment.
It's not the GC or TC responsibility to produce the report. The idea is that the TC/GC sponsor will update the GC/TC about the sandbox project. What I have in mind is mostly a health check, stating whether the experiment is still on track or if people just stopped working on that and we should pull the plug. This is not an update from us to the general public. Note that the TC/GC sponsor is someone who cares enough for the sandbox project, joining their regular calls. Producing this health-check report shouldn't be too much effort, especially if it's once a quarter.
text/0233-opentelemetry-sandbox.md
Outdated
| A low barrier to entry would be desired for the sandbox. While the process can be refined based on our experience, my initial proposal for the process is the following: | ||
|
|
||
| 1. Proposals should be written following the template below and have one Technical Committee (TC) and/or Governance Committee (GC) sponsor, who will regularly provide the TC and GC information about the state of the project. | ||
| 1. Once a sponsor is found, the TC and GC will vote on accepting this new project on the Slack channel #opentelemetry-gc-tc. |
There was a problem hiding this comment.
This is an acceptance process, not acceptance criteria. On what grounds are TC/GC expected to decide?
There was a problem hiding this comment.
I would leave this open for now. Each voting member can accept/reject the proposal based on their best judgement on what's best for the project.
text/0233-opentelemetry-sandbox.md
Outdated
|
|
||
| ## Prior art and alternatives | ||
|
|
||
| * One obvious alternative is to let users collaborate on their own accounts and organizations, as some are doing today. There are two problems with that: the first is that those projects usually lack clear governance rules, so that external contributors aren't sure what's going to happen with their code contributions. The second problem is lack of visibility: most of the current experiments and initiatives aren't listed in the [OpenTelemetry's registry](https://opentelemetry.io/ecosystem/registry/), and being under an OpenTelemetry organization would make those projects more visible while still at early stages. |
There was a problem hiding this comment.
those projects usually lack clear governance rules
Nothing prevents those projects from adopting the same license and code of conduct as CNCF/OTEL.
lack of visibility
This proposal in no way addresses the visibility problem. If the attempt is to address is by simply being in the otel-sandbox list of repos (which isn't very search friendly), then there are much easier ways of achieving the same (e.g. a page / registry on the website with minimum entry requirements) than having a sandbox program.
There was a problem hiding this comment.
Being part of the OTel repository certainly makes it more visible: a blog post mentioning "github.com/open-telemetry-sandbox/some-experiment" would certainly get more attention than "github.com/jpkrohling/some-experiment". Other than that, you are right that there are no active steps being taken to make those repos more visible.
|
@yurishkuro, I think I addressed most (all?) your comments. Let me know if they are acceptable, in which case I'd like to discuss the open question we have there about the arbitration of technical disagreements. |
|
@yurishkuro, can you take another look at this one? I believe I addressed your concerns, but I'd be interested in hearing if you'd still be against the general idea. I'm also interested in hearing from others, including the wider community, maintainers, and TC members. cc @open-telemetry/technical-committee |
There was a problem hiding this comment.
I don't think my or other people's concerns are addressed. You wrote some comments in the discussion, but the OTEP text still contains the same burdensome rules that impose an unnecessary process that takes time away from GC/TC, like frequent reviews / updates.
text/0233-opentelemetry-sandbox.md
Outdated
|
|
||
| There is a desire, but not an expectation, that projects will be moved from the sandbox as an official SIG or incorporated into an existing SIG. There’s also no expectation that the OpenTelemetry project will provide resources to the sandbox project, like extra GitHub CI minutes or Zoom meeting rooms, although we might evaluate individual requests. | ||
|
|
||
| Projects in the sandbox should leave it within one year, either by being merged into existing SIGs, being accepted as independent SIGs, or by being archived. |
There was a problem hiding this comment.
I think what you want is an annual review with possible outcomes being:
- continue as sandbox for another year
- graduate to official OTEL
- abandon project and archive the repo
- transition to another org if there is a better fit
This is not the same as "should leave within one year", which is often unrealistic, nor has a strong justification.
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
jpkrohling
force-pushed
the
jpkrohling/otep-otel-sandbox
branch
from
34b7b27 to
afb02d1
Compare
|
I updated this PR with a few changes, addressing the concerns expressed. I would appreciate another review round. |
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
|
Based on our discussion on the main issue, I'm closing this as I'm no longer comfortable with this proposal. |
Closes #231
Signed-off-by: Juraci Paixão Kröhling [email protected]