Update incubation guidelines

[krassowski]

This is to kickstart the work on updating the incubation guideline. As per discussion elsewhere the incubation process itself is a responsibility of SSC. I understand the guidelines should be proposed by SSC and probably blessed by EC consensus.

So far the changes made:

• Steering Council → Software Steering Council, except for:
  • direct subproject creation where it is the Executive Council that does that nowadays (by precedent of Jupyter Book incorporation)
  • proposal advocate where I think it makes sense to allow any member of the Union of Councils
• replaced references to outdated tooling like bower and Travis with current standards (yarn and GH Actions)

To do:

• are there any functions where EC (as a more direct successor to the old SC) should retain responsibility?
• decide if incubator org should be un-archived; if not then replace references
• confirm with broader SSC everyone is happy

This is:

• a follow-up to Add a note about jupyter-incubation being due a review #289
• relates to Incubator process contains archived proposal location and outdated documentation #256
• and Request to move all repos from jupyter-incubator into jupyter software-steering-council-team-compass#24

[ellisonbg]

@krassowski Thank you for getting this started! Before I dive into a line-by-line review, I had a few overall comments:

When the original incubator process was created, "Subproject" referred to a repo. However, in our new governance structure, most Subprojects are entire GitHub orgs (https://jupyter.org/governance/list_of_subprojects.html). Because of this, there are a couple of incubation routes we probably need to distinguish:

1. An individual repo that can be incubated in an existing Subproject. In many ways, this is ideal as we want to constrain the overall number of github orgs and Subprojects from growing too much. For this case, my sense is that we should encourage applicants to consider this option, and delegate responsibility to the individual existing Subprojects (this is more or less what we are already doing, but would be helpful to call this out).
2. An individual repo that can be incubated in the Jupyter incubator org. This use case is closest to the original incubator model, and we can probably un-archive the incubator org for this use case. I do think this case is still relevant - for example, we probably would have used this for Jupyter AI if the process had existed at the time (instead we have incubated it in the frontend subproject).
3. New top-level Subproject that is an entire GitHub org. We should think about how we want to handle this use case, as incubating projects that do start to grow will likely need an GitHub org along the way. This too has happened to Jupyter AI, which now has https://github.com/jupyter-ai-contrib. Ideally, we could soon move the jupyter-ai repo to that org soon and have the whole org as under incubation.