A focus on healthy governance is an important consideration as we look across the project levels. Seeding small portions of governance requirements upfront positions the project for future success. In this regard, having aspects of each category of project requirements (e.g. adoption, governance, and so on) included in each project tier (growing progressively stronger with each tier) make good sense.
I see business models as relevant, but orthogonal to project requirements. If a project meets criteria of being useful (in part what I consider TOC sponsorship to convey), adopted; having healthy governance, being securely architected, and so on. Why would we need to consider whether current or future organizations (that are contributing or have never contributed) will use the project as an open core component of an offering, or something to run as SaaS or wrap pro-serv around?
As far as I understand the requirement the goal is to avoid pure OpenCore projects to be CNCF projects. Additionally, having multiple organizations as maintainers will ensure project continuity of the organization initially driving the project would lose interest. Maybe having the requirement to have substantial PRs coming from multiple organisations would also partly serve this purpose. Most open source projects require substantial contributions to become a maintainer anyways. // Alois FWIW I am uncomfortable making multi-org governance/maintainership a requirement of incubation, since this requirement has been contentious even at graduation level, and I know that several of our existing incubation projects do not satisfy this requirement. I would rather see us nail this at graduation and allow incubation to be a time that multi-org governance/maintainership can be nurtured. On Mon, May 11, 2020 at 10:48 PM Bob Wise < bob@...> wrote: "Sandbox is for experiments and early stage projects" Isn't that part of what we are debating here? I wouldn't agree that multi-org projects are incapable of innovation and experiments. It might even be the case that multi-org governance improves innovation. On Mon, May 11, 2020 at 10:54 AM Matt Farina < matt@...> wrote: I'd like to unpack this part of the thread... A much stricter requirement for multi-org governance as entry even to sandbox would help avoid project dumping by a single company.
Multi-org governance is a graduation requirement. Sandbox is for experiments and early stage projects. Adding multi-org governance would squash the goal of experiments and early stage. if it has been around for a good few years already, and still has little adoption, it's probably either a bad idea, or doesn't work
This is a huge question. To start, what is "little adoption?" Incubation requires 3 running it in production. That's a metric. "little adoption" gets complicated when a project is more of a niche, too. Cloud native has a bunch of niches. If only the widely used projects should go in that's totally fine. Just worth communicating. But, this is sandbox. Do we want sandbox to have usage requirements higher than incubation? I wonder, if we say sandbox is for innovators (to quote the docs) that means a number of experiments and early stage projects are going to exit there. Can we say the experiment needs to be viable as a criteria and the TOC is the judge of that? I'm skeptical on the "bad idea" part because that's very subjective. Who knows the technology, markets, and users well enough to really do this? It's a hard thing to do. An experiment that's been running for years, has had blog posts, has had videos, and all that stuff but has failed to move the needle may not be a viable experiment any longer. It's hard to hear but it happens. This is different from the good idea or bad idea because it's not looking at the quality of the work but rather if the experiment has the capability to live on. Bad ideas can catch wind and have life. Good ideas can die. Plus, the CNCF staff has been doing work on metrics to look at project health. This may be something they can analyze as part of their work on the submitted projects. On Mon, May 11, 2020, at 12:53 PM, Bob Wise (AWS) via lists.cncf.io wrote: Don’t we want the CNCF to be a home for good projects, not just big projects? A much stricter requirement for multi-org governance as entry even to sandbox would help avoid project dumping by a single company. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. |
Nit pick: “if it has been around for a good few years already, and still has little adoption, it's probably either a bad idea, or doesn't work” There are many reasons that a project may be in this situation. It isn’t just because the project is bad/doesn’t work. Perhaps we should say that it isn’t a good fit for the CNCF as the CNCF isn’t just a way to get attention/marketing/adoption for a project that is otherwise stalled. Joe Thanks for these thoughts, Quinton 1. Add some measures to avoid becoming a dumping ground for failed company projects. Even if a project checks all the boxes, if it has been around for a good few years already, and still has little adoption, it's probably either a bad idea, or doesn't work.
100% agree. As I don't think this is limited to Sandbox, I wonder if this would be better added in, say, the Principles doc, wytd? 2. Add a 'public review' period of about a month. I think it's beneficial for the community to have visibility of what's heading towards sandbox, ask questions etc.
Yes, the idea is that this should be public. We need some way of holding a public comment period in a lightweight fashion. Perhaps whenever a form is submitted, it also generates an email to the TOC mailing list so that folks are aware and can reply with thoughts about it. 3. The original thinking around TOC 'sponsors' (and there's probably a better word for them) was to have some show of support from the TOC for a candidate sandbox project (equivalent to 'yes, that seems like a good idea'). If no TOC members want a project in the CNCF, for valid reasons, then it presumably shouldn't be there, irrespective of what boxes it checks. I think you'll need some way to achieve this. Perhaps announce at the TOC meeting the list of projects that have checked all the boxes (with a brief description of each) and are eligible for sandbox, and give the TOC public veto rights at that point?
We're suggesting a simple majority vote from the TOC. This raises the bar in the sense that a majority, not just three TOC members, need to support a project, but hopefully the aggregate extra work for individual TOC members will be more than outweighed by having less lobbying to deal with, and it will be much clearer for the whole community. On Wed, May 6, 2020 at 4:38 PM Quinton Hoole <quinton@...> wrote: Yes, this is very close to the intentions I always had in mind, but which I don't think were ever written down clearly, or particularly well executed on. Great job ckarifying.! 1. Add some measures to avoid becoming a dumping ground for failed company projects. Even if a project checks all the boxes, if it has been around for a good few years already, and still has little adoption, it's probably either a bad idea, or doesn't work. 2. Add a 'public review' period of about a month. I think it's beneficial for the community to have visibility of what's heading towards sandbox, ask questions etc. 3. The original thinking around TOC 'sponsors' (and there's probably a better word for them) was to have some show of support from the TOC for a candidate sandbox project (equivalent to 'yes, that seems like a good idea'). If no TOC members want a project in the CNCF, for valid reasons, then it presumably shouldn't be there, irrespective of what boxes it checks. I think you'll need some way to achieve this. Perhaps announce at the TOC meeting the list of projects that have checked all the boxes (with a brief description of each) and are eligible for sandbox, and give the TOC public veto rights at that point? I can move these comments to the doc if needed. I'm not at my computer right now. On Tue, May 5, 2020, 09:06 Liz Rice <liz@...> wrote:
|
