I check my spam and found a mail send to [email protected]
It was the wrong email, just a question about nbviewer. I responded but am concerned it was flagged as such.

@mpacer, @willingc and @Ruv7 any advice ?

@takluyver raised this some time ago as a meta discussion in some email thread to the SC.

Copypasting here to prevent loss of information and to push the discussion a little bit more 😉

Do we have a process written anywhere for inducting new maintainers on Jupyter projects? I think we want people who know a particular project to be able to select extra maintainers themselves, especially as the rest of us are mostly going to +1 any recommendation from someone we already trust. But at the same time, someone with commit/publish access to Jupyter projects has a pretty good opportunity to spread malware, so we need to have a degree of trust in them, and rely on them to keep their credentials suitably secure.

For instance, we might want to require some combination of:

• We know their real identity (i.e. something that looks real - I'm not proposing we ask for passport scans)
• Minimum age of Github account
• 2-factor auth enabled
• Write them a few sentences to remind them to take their account security seriously.

#51 is actually one of above points...

Description

I really like that the decision-making guide encourages projects to "seek consensus" in its conversations, even though we recognize that this may not be possible, and a vote is often required.

That said, I have found that "seek consensus" is an under-specified process and can be a high bar for more complex decisions. I wonder if it would be helpful to recommend "consent seeking", with links to some materials that describe what this means, as a more explicit and pragmatic approach.

Benefit

I think that framing decisions in terms of consent could have a few benefits:

• It is generally a more pragmatic decision-making approach, by reframing decisions as "do you have any major problems with this?" rather than "is this the decision that you want?" (which is often hard to achieve).
• It provides a framework (e.g., this guide or this guide) for carrying out decisions and discussion in an inclusive manner.

Implementation ideas

It might be enough if we simply referenced these resources in the decision making guide, since "try to seek consensus" is not really an official policy anyway, more like a cultural norm, this could similarly be an informal recommendation.

Edit: Note that I don't believe this is suggesting an official "change" to the decision-making process, this is just for the first section of the decision-making guide, in case it could be a useful approach to use.

Hey y'all

I am opening this issue as @isabela-pf @tonyfast and I are working on a CZI EOSS proposal on accessibility for Jupyter

See issue: jupyter/accessibility#36
Submitted letter of intent: jupyter/accessibility#44

I know there is no formal process (yet) to apply for funding but there are a couple of discussions happening in #96 and #97 hence I would like to request formal approval from the steering council to move forward with this work

Let me know if there is any other information I'd need to provide

Should it be mention somewhere ? Be put in a subproject ?

Like #100, I am writing a proposal for CZI to fund work on collaboration on infrastructure around JupyterHub deployments

The proposal will be submitted by Simula, due May 19.

More info with links to draft documents and prior discussions: jupyterhub/team-compass#403

Let me know if anyone has questions or concerns

_

https://github.com/jupyter/governance/blob/master/conduct/enforcement.md

In this document it was written that the code of conduct committee will be filled in.

In a recent community forum thread, it became clear that several members across the Jupyter community were planning on applying for an EOSS grant. There wasn't a lot of community-wide coordination for this, and as a result there are a few ambiguities that surfaced at the last second. For example, the JupyterHub community discussed this in their team meeting and team compass, and the accessibility working group discussed this in an issue, but these efforts weren't obvious to the broader community.

I think that we should discuss these ambiguities and have community-level guidelines for some of them. Here are a few questions that I think are unresolved:

1. If an organization wishes to apply for funding "as the Jupyter project", do they need to follow any particular process?
2. How do we define if funding is meant "for the Jupyter Project", vs. "for a project that happens to involve Jupyter development"?
3. Do we require that community members notify the broader community and invite participation before pursuing these kinds of funding opportunities?
4. Do we differentiate between the sub-communities within Jupyter? (e.g., JupyterHub and JupyterLab)

Ultimately I think that there are two important things that we should keep in mind:

1. Access to funding opportunities should be managed in an equitable and participatory way, so that some in the community are not excluded from opportunities just because they didn't notice them, or weren't informed.
2. Applications to funding will benefit from having input from a broad range of perspectives from the community. Both in making the application itself more competitive, and in ensuring that its deliverables represent the needs of the community.

I think that it is too late for this to be resolved for the current EOSS round, but flagging these issues for future discussion.

It has already been mentioned in discussions, and it's highlighted on @captainsafia's newsletter, that there's great value in having CoC docs available in multiple languages.

I don't want to delay our moving forward for this issue, but also don't want to forget about it. This is something where community members can help us by contributing a translation to a language they are familiar with.

Once #23 is merged (so we have a known target for translation) we should try to at the very least have versions in

• Spanish
• French

as I think those are the two other languages with significant representation in our "regulars". Obviously this shouldn't be read as ignoring other languages, just flagging the ones to try and target first for considering this issue target met (we'll always welcome translations to any other language).

/cc @SylvainCorlay who mentioned this recently...

We will include language in the gov repo strongly encouraging two-factor authentication for users with push-access

Per discussion at team meeting @ellisonbg

Hi y’all

Thanks for all the hard work put into the new governance structure and associated processes.

I had a look at #121, and I am so thrilled to see pathways to acknowledge, formalise, and support long-standing non-code contributions in our ecosystem.

However, looking at this PR also raised several questions/doubts on my end and I will do my best to elaborate here.

Accessibility is listed under the Working Group category in said PR 🎉. However, I wonder why this is not listed under the Software sub-projects.

As per https://jupyter.org/governance/software_subprojects.html the whole accessibility project fits the description and meets most of the requirements for being recognised as a Software SubProject, namely:

• Adheres to the Jupyter CoC
• Follows the licensing guidelines - under a BSD-3 license
• Follow Jupyter’s trademark, branding, and intellectual property guidelines.
• Conduct its activities in a manner that is open, transparent, and inclusive
• it is already under the Jupyter GitHub organisation

In addition to the criteria for official sub-projects https://jupyter.org/governance/newsubprojects.html#criteria-for-official-subprojects:

• Have an active developer community that offers a sustainable model for future development.
  • Holds regular community calls and all are properly documented and recorded
  • Leading Jupyter community workshops to raise awareness of accessibility principles and share knowledge and best practices for scientific computing scenarios.
  • High impact decisions and general project updates are shared with the broader Jupyter community through community calls, issues and discussions both on GitHub and Discourse, and attending other projects’ community and projects calls
  • Additionally, folks from the accessibility working group are currently working on the CZI Accessibility grant which is all documented and developed in the open at https://github.com/Quansight-Labs/jupyter-a11y-mgmt and https://github.com/jupyter/accessibility, plus the team has made an intentional effort to keep the broader community informed on its status and seek feedback along the road (from grant proposal to execution)
• Use solid software engineering with documentation and tests hosted with appropriate technologies (Read The Docs and GitHub actions are examples of technologies used).
• Demonstrate continued growth and development.
• Integrate well with other official sub-projects.
  • This project started as a grassroots advocacy movement. Since its inception, it has focused on building bridges with other projects such as JupyterLab, Jupyter Widgets, and Jupyter notebook, among others.
• Be developed according to the Jupyter governance and contribution model documented here.
• Have a well-defined scope.
• Have an active user community.
  • To achieve Jupyter’s values of being an inclusive project, we have to ensure accessibility sits at its core. Any improvements in this area positively impact the whole user base of Jupyter and its sub-projects.
  • The above point also implies significant buy-in and collaboration with the sub-projects maintainers

Additionally, I know these items are in the works:

• Be packaged using appropriate technologies such as pip, conda, npm, bower, docker, etc. (already present but being improved)
• Maintain a publicly visible Team Compass

The ask

I would like to propose incorporating https://github.com/jupyter/accessibility as a Jupyter official Software sub-project, given that it already satisfies the criteria set for this purpose.

Please note that I am not proposing replacing the Working group - I instead believe that these two are complementary to each other since:

1. The whole accessibility area includes significant efforts that fall under the no-code contributions such as:
   1. advocacy and community organisation
   2. education around accessibility, best practices, and disability inclusion
   3. influencing policies and guidelines
      1. technical: best practices for disability inclusion, auditing processes and contribution workflows
      2. documentation aimed at developers around accessibility
      3. DEI (diversity equality and inclusion) - supporting and collaborating with the broader community and the DEI Working Group towards disability inclusion
   4. establishing contribution pathways for disabled users and contributors
   5. bridge the gap between scientific computing and the accessibility community
   6. outreach activities such as conference presentations and workshops organisation
   7. seeking funding to address accessibility issues and barriers
2. It also involves significant code-related work:
   1. Auditing of existing software
   2. Generation of roadmaps and execution of accessibility improvements
   3. Accessibility testing (both manual and automated)
   4. Direct contributions to the codebase to ensure tools are accessible (mostly to other Jupyter software sub-projects)
   5. Developing tools, workflows, and packages to support and enable the above activities

I believe recognising these two branches of accessibility work is the foundation for making progress towards whole inclusion and better serving the global Jupyter community. It is a goal that cannot be done only through advocacy/community work or only through code contributions, to be successful it has to be a multidisciplinary effort.

Also, note I purposely did not follow the process outlined in https://jupyter.org/governance/newsubprojects.html#proposal-for-incorporation, i.e. creating PR against the https://github.com/jupyter/enhancement-proposals repository since the repository in question is already under the Jupyter GitHub organisation. But it is not acknowledged as a software subproject.

If needed, I am happy to go through the formal process of submitting a JEP. But I thought I would raise it first here as an open discussion/question given the project's current status.

Some time ago Ralf Gommers pointed out to me that some of Jupyter packages are available on tidelift with subscriptions.

I got a response from tidelift, and for this process one of the devs need go with the tidelift agreement.

I would be happy to sign this agreement, still need to make sure I can as I'm in europe, but mostly for the involved packages this adds a bit of overhead on maintaining the projects as there might be some communication that needs to happen with tidelift on new releases/security. So while accepting legally bind one person, it affects a bit all the maintainers. So I'd like to have the approval of the jupyter communities and subgroups.

It is also something that is not well defined for a particular subprojects, if it is please let me know which one.

As most of the tidelift requirements are around security I am suggesting that funds we would get for tidelift would be deposited to NumFOCUS mostly into a security specific funds that may be touched only for security related work and workshops.

The three main packages that seem to be worth it are:

• IPython/Pypi which would generate ~$800 / month
• traitlets/Pypi ~$110/month
• conda/ipython ~$140/month

Others don't seem to be worth it:

• ipython_genutils/pypi $40/month
• nbformat/pypi $40/month

(I haven't checked all packages, search on tidelift is a pain, feel free to tell me if I missed some).

And other I have no clue how to maintain them

• appnope/pypi $50/month @minrk might be interested in signing as well ?

It is not clear if conda refer to conda-forge of anaconda base channel, in which case we would need anaconda involvement.

Assuming I sign the agreement, I'd like some of the fund to be usable by me to actually reserve some of my time to do tidelift related task and manage some of the security process.

This may be one of the source that may help to fund @choldgraf #125.

cc @rpwagner and @rcthomas as it impacts some of the security work.

I also need to read the agreement and the list of things to do for tidelift more carefully, but according the the discussion I had with others it should be worth it for the project.

Hi everyone. Today we had an active governance office hours today with myself @fperez @jasongrout @afshin @willingc @Zsailer @tgeorgeux in attendance. One of the topics that @willingc brought up was the challenge of cross org/repo communications. Jupyter is a vast project now, and it can be nearly impossible for any individual to follow everything that is going on. Communication around governance is one part of this, but it impacts all work on the project.

In the conversation, an idea began to emerge about establishing a lightweight mechanism to enable the Jupyter community to follow what is going on across our orgs, repos, and working groups on monthy basis. Here is the rough sketch (please help us iterate on this):

• Create a GitHub repo for collection and presentation of monthly update information (see below for more details about what type of information we are thinking about).
  • We talked about reusing our existing jupyter/newsletter for this, but maybe another makes more sense?
  • Publish the relevant markdown docs in this repo using GitHub pages.
• Have each GitHub organization under the Jupyter umbrella (see question 1 below) appoint a communications person that would own the collection of the monthly information for that org.
  • That person could work with contributors on that org however they see fit to collect the information. For example, on a big org, they could delegate other people who provide information for individual repos.
• Once a month, the communications person would:
  • Work with the org-level contributors to collect the information.
  • Submit a PR to the appropriate markdown document on the central repo.
• What type of information?
  • We want the information to be easy to write, collect and publish–in the form of bullet points in complete-ish sentences with a link.
  • Under the broader umbrella of "what interesting work is going on?", bullet points should address the following types of questions:
    • What work has the org/repo done over the last month?
    • What releases have the org/repo made over the last month?
    • What work is happening over the next month?
    • Big questions or challenges the org/repo is wrestling with, especially those with cross project impact?
    • What ongoing meetings is the org/repo having that others can attend.

Questions:

• For this purpose, do we want to include "adjacent" open source project that are not formally under Jupyter's governance (model QuantStack, nteract, etc.)?
• @Zsailer may be willing to help us get this started as the coordinator. It would be helpful to have others help in this - maybe the communications person for the orgs can rotate monthly?
• Should the non-GitHub working groups (governance, inclusion and diversity, jupyter community workshops, jupytercon, etc.) also report (I don't see why not)?
• What repo should we use?
• What are the monthly dates for reminders, the PR submission, etc.
• How should we organize the markdown documents into folders across dates and project areas?

Based on discussions and encouragement (particularly from @afshin and @blink1073) during the jupyter-server call today, @rcthomas, Tiffany Connors, and I (@rpwagner) would like to establish the Jupyter Security Subproject. Our work planning the Jupyter Community Workshop on security best practices has broadened, and includes an engagement with TrustedCI. With the additional support from TrustedCI, we can begin working on security-related activities ahead of the workshop, such as policy recommendations, or secure development practices.

During today's call, the jupyter_security repo was set up under the jupyter-server org as a starting point to capture this work. Later, this could become the team-compass repo for the Subproject. It was also recommended that we create a post on Discourse to let the community know about the Subproject. What should be included in the announcement? E.g., meeting times and location? We want to ensure we have the minimum structure needed to work with the rest of community.

We're looking forward to any feedback on this idea. I will try to attend the July 30, 2021, governance call to see if there is any discussion around it.

Hi all

As many of you might be aware a few folks and I are working on a CZI EOSS proposal to tackle accessibility issues in the Jupyter ecosystem.

In the proposal we have to provide information regarding Existing support to the Jupyter ecosystem, esp:

List active and recent (previous two calendar years) financial or in-kind support for the software project(s), including duration, the amount in USD, and source of funding. Include in this section any previous funding for these software projects received from CZI (maximum of 250 words)

Since there are 4 proposals being worked on atm I was wondering if there was a way to have this information and share with the rest of the folks working on proposals.

For reference here is the Discourse item where we are keeping track of the proposals:
https://discourse.jupyter.org/t/coordinating-czi-eoss-applications-across-the-community/8472/13

cc/ @choldgraf @Carreau and @minrk who I know are the respective PI's in the other proposals

During JupyterCon sprints, one of the topic was to update our various repositories to ensure uniforme licensing terms. We got ~50 Pull-Requests about this topic and a few issues appeared or were discovered. This is thus an issue to discuss the licensing Guidelines.

A) LICENCEs files were added without consideration of Pre-existing COPYING files.

B) COPYING were renamed to LICENCE without updates of Manifest.in files leading to releases being uploaded without being Properly licensed.

C) Previous Copyright were removed or about to get removed

D) MIT project were almost relicenced as BSD without authors consents

D') Projects without licenses were added a BSD Licence without all authors approval

E) Some projects (docs, website tutorial) Got BSD and should get CC0?

F) Copyright Dates we updated to 2017

I'm Going to Focus on F in the following paragraph, but if we get a Guideline it would be good to cover other points.

According to Brian:

Here is the US law on copyright notices:

https://www.copyright.gov/title17/92chap4.html#401

tl;dr - we should use the first year of publication and don't need to
put -present as copyrights don't expire.

Jason pointed out :

• While the year is the date of the first publication, you may (should?) also list other years that significant contributions were made, as their copyright starts the year those contributions were published.

Fernando

Quick note - at the sprints in NYC on Saturday we had a brief chat about trying to simplify this as much as possible to avoid all that churn... I suggest we seek the simplest solution that is compliant with law but that avoids all the "January copyright update storm".

If simply listing file creation year is legally sufficient, I'm all for that. Like in many other areas, times of significant activity are adequately recorded by the VCS, so I don't think having a bunch of years listed in the file (or an updated endpoint) is really of any use.

And Paul

I left this as a comment in a recent JupyterLab PR that bumped the copyright verison: we moved to remove the end copyright date from files as we updated them in IPython starting back in 2012. The reason is that it keeps you from having to have a noop commit once per year that updates the whole repo's end dates. For more on this discussion, see ipython/ipython#1644

So can we get a clear guideline ni this repo and check all the PRs that have been recently made.

Note: We're asking other project to correctly use our licensing terms when they use some of our code, so let's do things properly.

Hi folks! I am creating an image about Jupyter and Git/GitHub for an intro textbook (https://ubc-dsci.github.io/introduction-to-datascience/) we are writing and I want to get permission to use the JupyterHub logo in it. Is this the right place to ask for permission? If not, can you please point me to where I should do this?

NumFocus has their annual summit on September 22nd and 23rd in the Bay Area. I haven't see any threads or conversations around this in the Jupyter world, so I thought I would open an issue and see if anybody is planning to go. Presumably they are only offering this to people who are on the Steering Council? Either way I thought it would be useful to surface this publicly and see if there's a plan to have representation there.

FYI I will likely attend the CZI EOSS summit that happens just before this, and if I do I might be able to join the NumFocus summit, but I am not sure because it'll be quite a lot of time away from my kid at that point. If it would be particularly helpful to Jupyter, I can make the time to attend, but if somebody else prefers to go I think that would be better.

see #23 (comment)

@willingc proposed this addition to CoC in previous P, linking to it from here not to forget.

#23 (comment)

https://github.com/jupyter/governance/blob/master/conduct/enforcement.md#how-the-committee-will-respond-to-reports

Reporting Guidelines link is broken, asterisks

We have now receive a trademark on the Jupyter logo and should update the trademark usage document to reflect that. Our lawyer recommend the following language be added to usages of the logo:

"®" or "Reg. U.S. Pat. & TM Off." or "Registered in U.S. Patent & Trademark Office."

See also jupyter/jupyter.github.io#250

To help us quickly collect topics for our August 2017 team meeting, please enter comments and upvote existing comments. We are short on time (only two days), so this will help us to surface the most pressing discussion topics.

https://paper.dropbox.com/doc/August-2017-Team-Meeting-Agenda-NvwrkTa47sUQJbRjDwfzN

(like #107 this one came up in the private Steering Council group and we wanted to open it up for public discussion and eventual voting).

Currently we manage project wide passwords using a painful combination of KeePass and a shared Dropbox folder. NumFOCUS has an organizational 1Password account that we could use for this purpose. I propose we adopt that approach and work with NumFOCUS to migrate our shared passwords over there.

On recent transitional Jupyter Executive Council calls, we have been working on the timeline for the transition. Please find our current timeline below.

In jupyterhub/team-compass#424 we're discussing some challenges around designating shared ownership and control of mybinder.org. It's currently under my personal account, and I'd like to somehow move to a shared ownership model.

However, we aren't sure what domain registry service will allow for something like "shared ownership". I believe that NameCheap allows for shared access / management but not ownership.

Does anyone know if it is possible to have "shared" ownership of a domain like mybinder.org? E.g., could I donate it to NumFocus as an asset that is handled similar to other Jupyter assets? And if so, what kind of registrar service should we use to ensure that the Binder team still has easy access / control over its usage?

More generally, something we should figure out as part of the governance re-working is what kind of policy we want for "Jupyter-related domains", and what process we recommend to carry out that policy.

From @rgbkrk at jupyter/enhancement-proposals#11:

Rather than go back and forth in a PR to accept a proposal, how about we accept a PR and call it a draft state. When we've accepted it, we make a PR to update the status. If it's deprecated, not implemented, etc. we make another PR to address that.

@ellisonbg asked that the decision be handled over here.

We have a few open enhancement proposals that are in a "yes, this is a good idea, more details later" state, but haven't been merged because the criteria for that are unclear.

This would make it easier to merge earlier and iterate on ideas.

It looks like there is a cryptocurrency venture using the Jupyter name and claiming copyright:

• https://jupyter.tech
• https://github.com/Jupyter-Network

They also have a thing called Jupyter Labs (buh).

I don't know who's running the trademark/copyright show, but it seems like something that should be handled at the governance level, as it pretty clearly has nothing to do with tools for interactive computing.

We (QuantStack) are working on a CZI EOSS 5 proposal targeting the documentation and maintenance of JupyterLab v4 & Jupyter Notebook v7.

As discussed 10 days ago, the proposal is focusing on the known and unknown (will happen after the release) challenges relevant to the major technological stack shift of Jupyter Notebook v7 (the backend will be the independent jupyter server and the frontend will be built from JupyterLab plugins).

The draft letter of intent is opened at jupyterlab/frontends-team-compass#140.

This request of approval follows the process done for the CZI proposal on accessibility #100. Hence we (QuantStack) would like to request formal approval from the steering council to move forward with this work.

Don't hesitate to comment and to propose changes on the current letter of intent.

Hi all,

Can I request that the governance document itself (or perhaps this whole repository for simplicity) be relicensed under something even simpler like like CC-0? Currently it has the standard 3-clause BSD, but I'm actually uncertain how to fulfill those conditions for the numpy governance document (which is a derived work from yours -- https://github.com/numpy/numpy/blob/master/doc/source/dev/governance/governance.rst). The BSD talks about requirements for source and binary distribution (??) and having to include a large notice in our documentation and stuff. It seems inconvenient at best.

Practically speaking I think the mechanism for this would be that everyone who's contributed text would have to say that they agree to the relicensing (if that's true :-)).

A discussion was started by @afshin about delegating/abstaining a vote in his absence.

Suggestion from @Ruv7 was:

I didn't do a ton of research (see attached questions to consider) but due to the timing what I believe would be a simpler approach would be for you to abstain from urgent voting during the specified time periods.

@afshin and several following the thread agreed. We should formalize this idea and include it in the governance document.

We need to have an official policy that clarifies how 3rd parties can use our jupyter tradmarks (name and logos).

This is an issue to keep track of some "meta" research as a part of the Mozilla Open Leaders program. There are lots of open projects out there, and they've all got their own take on how to effectively organize open communities. As I read and learn more, I'll keep this issue updated with information in case others are interested or have thoughts of their own!

Interesting links

• Python has a PEP for changing its own governance model in the wake of Guido taking a step back.
• Python also has a PEP for surveying other project models which is a great list for inspiration (similar and more complete than this one).
• The Rust community has a great teams page on their website. I love the fact that teams have explicit responsibilities and that there are lots of non-technical teams in there!
  • The NPM community also adopted this process for its own "proposal changes and feature requests" activity. (thx @nayafia!)
  • Ethereum also has a similar process though I believe they require all new RFC proposals to be discussed in one of the "all dev" meetings
• Moreover, the Rust RFC proposal list is a really interesting read if you wanna see a list of "big decisions" in the Rust community over the last few years. In fact, there's an RFC that proposes the current RFC system. :-)
• I also heard about the Mozilla Archetypes of Open Source white paper, which describes many kinds of open source projects. Seems like a useful resource as we think about the Jupyter community.
• The Mozilla project governance is split into "modules". Each module has a core team and a module owner that makes decisions.
  I'll keep this list updated as I hear of more! If you've got any suggestions for links, comments, etc please post below!
• Here's a fascinating series of blog posts about hybrid organizations from one of the leaders in the Mozilla community. Lots of interesting conversation about how a public/private organization can more effectively balance being mission-driven but also scaling to have an impact on markets in order to further that mission.
• The Apache foundation describes their voting process and the different nuances that come with voting in different scenarios and with different groups of people.
• An excellent blog post on the Node.js contributor model
• Some general model frameworks for open source governance
• A great set of slides on the "Liberal Contribution" model that has been adopted by modern-day projects like node and Rust from @nayafia
• The Kubeflow governance model is pretty interesting to look through as well

Having just run a 4-hour mini sprint, I have noticed that GitHub uses the labels help wanted and good first issue in a new feature which searches for issues for new contributors. See screenshot below:

What do we think about switching our new contributor type labels to this convention for improved search engine optimization?

I think making the switch would be preferred since we want to make it clear which issues are appropriate for new contributors. At the same time, I understand this would change our labeling conventions by team and that this should be considered on a repo-by-repo basis.

Do we have style guides for our repos or ones we prefer?

Google has just shared their style guide for documentation:

https://developers.google.com/style/

Hey all - a few times now we have had people show up on the community forum (I think this has happened on the listserv as well but we don't really have control over the tech there as much) being rude, unhelpful, or otherwise confrontational.

I have a personal approach to how I deal with these situations (generally, a polite note of what the person is doing wrong and locking the thread) but I think it'd be helpful for Jupyter to have guidelines for how people should handle these situations in general.

I believe that these kinds of situations don't merit an official CoC violation report, since usually it is from people who aren't active in the community and going through an official process for every jerk on the internet would be a time-consuming process. Instead some language about "if you fail to abide by XXX rules in public forums that Jupyter controls, you can expect YYY to happen" would be helpful.

What do people think about this? If folks are +1 I can add some language in a PR.

Hello. Thank you all for the great work being done toward solidifying the governance model - this will be a tremendous benefit to the health of the community. I realize I should have raised this prior to the model's merge, but felt the other discussions were more important and, honestly, wasn't sure if it was my place to chime in.

I'm concerned that the Jupyter Enterprise subproject's "foundation" will be tenuous from the start and will struggle to meet the participation needs of the model. It also feels a bit like an Island of misfit toys in that the only project specifically targetting enterprises is Enterprise Gateway.

Although I can't speak to docker-stacks or nbviewer, I can safely say both Kernel and Enterprise Gateway are (today) maintained by a couple of maintainers with Kernel Gateway's traffic quite sparse and EG's not far behind. Since these two projects are direct subsets of Jupyter Server (JKG is currently based on notebook, but is identical to server) and require the same technical expertise residing within the Jupyter Server organization, they strike me as better-suited to the Jupyter Server subproject.

Assuming we did relocate the gateway's into Jupyter Server, that would leave docker-stacks and nbviewer as the only projects in Jupyter Enterprise, both of which are widely used outside of enterprises. Seems they could be logically included in Jupyter Foundations, a different sub-project, or in the set of projects w/o SCC representation.

I just feel like the current incantation of Jupyter Enterprise is fragile from a participation/community presence perspective and felt this should be raised before actual representation is established.

Thanks again for all you're doing to improve the community!

What do folks think about adding a .github/FUNDING.yml file to the Jupyter GitHub organizations so that a "sponsor" button shows up?

We could point the sponsor button to: https://numfocus.org/donate-to-jupyter

In the Jupyter governance, it indicates that when a project is adopted by Jupyter, it should use the license specified in the governance: https://raw.githubusercontent.com/jupyter/governance/master/projectlicense.md, which is BSD.

According to this, the license in, for example, https://github.com/jupyter-widgets/ipyleaflet/blob/master/LICENSE probably should have been changed from MIT to BSD when it was adopted as a Jupyter project.

However, according to the main governance document, "The Software developed by The Project is released under the BSD (or similar) open source license". I think MIT would qualify as "similar" to BSD.

So which is it? If a project is incorporated into Jupyter, should it be converted to BSD for consistency with other Project Jupyter software, or is it fine to stay, say, MIT licensed? ("converting" I think more properly means that the LICENSE file changes to BSD, but it retains the MIT copyright notice for code before it was adopted into the project)

It would good for us to have clarification on the intent and our interpretation. I don't know of any other Project Jupyter projects that are released under licenses other than the standardized BSD project license.

CC @ellisonbg (original author of ipyleaflet), @SylvainCorlay and @martinRenou (main current maintainers) of ipyleaflet.

For the record, I'm okay with an official subproject being MIT licensed if it was licensed MIT before being adopted. I think new projects that start in Project Jupyter should carry the project license.

See this subthread:

#23 (comment)

See the sub thread here:

#23 (comment)

There are a number of Jupyter contributors and stakeholders who are writing grants for the CZI EOSS program (https://chanzuckerberg.com/eoss/). Here are links to some of the discussions and issues on this topic:

#96
https://discourse.jupyter.org/t/coordinating-czi-eoss-applications-across-the-community/8472/3

Today in the governance office hours we (@fperez @blink1073 @choldgraf @afshin @ellisonbg) discussed how we might create a lightweight process that encourages collaboration and transparency among those working on these and other Jupyter related proposals and grants.

Here is the proposal we came up with:

New jupyter/proposals repository

We propose creating a new jupyter/proposals GitHub repository to use for collecting information about Jupyter related proposals that contributors and stakeholders are working on or have submitted previously.

Issue Template

We propose creating an issue template in that repository with the following content:

Issue Template Title: Jupyter related grant proposal submission

What is the working title of your grant proposal?

What Jupyter individual contributors are writing and submitting the proposal?

Please share a public link to the proposal narrative (draft is fine):

Please share links to any public discussions in the Jupyter community about your proposal (GitHub, Discourse, etc.):

What Jupyter subprojects will this proposal involve?

Will your proposal be submitted and managed by NumFOCUS or another organization?

If not NumFOCUS, what organization(s) will be submitting the proposal and managing/spending the funding if granted?

After this issue is discussed, review, and merged:

- You must add the following text to the submitted version of your proposal, along with a reference to this issue number NN (make sure not to make it a hyperlink if your agency guidelines forbid that): “This proposal has been publicly shared with the Jupyter community and has been approved for submission by Project Jupyter (JFP NN).” 
- Once you have submitted the final version of your proposal, please submit a Pull Request to this repository with a static copy of the final proposal narrative as a public record of the submission. You can optionally include LaTeX, markdown, etc. sources if you want, but please minimally include a static PDF version.

Call for people willing maintain the jupyter/proposals repository

At this point we are not proposing that the Steering Council formally approve these issues or proposals. Instead, we thinking of a group of volunteers who maintain the jupyter/proposals repository. These maintainers would review and comment on the issues and PR requests submitted to the repo, develop and maintain documentation, etc. and pull in the other governing bodies as needed. Who would like to volunteer to help with this?

It's a single click in the github UI and will do all the redirect, and will keep this repo consistant with all the others

Hey all - for the next several weeks @Carreau and I are participating in the Mozilla Open Leaders program - it aims to help projects build open, inclusive communities.

• Here's a link to the program syllabus in case you'd like to check it out
• Here's a link to another GH issue on community structures/governance

As a part of the program, we're working on a project associated with the community we represent. For our project, our goal is to increase the focus on the Jupyter community. Our hope is to come up with ideas to increase the transparency of how others can contribute to the various projects in Jupyter, and to build some team tools and norms for how we can be a more inclusive community.

We'd love any thoughts or input from folks as we move forward on this project. I'll keep updating this issue periodically as we find interesting information or brainstorm any new ideas. <3

Wrapping up: Overview and general thoughts

Hey all - last week we wrapped up this round of the Mozilla OL program. I just wanted to give a few parting thoughts on what I learned throughout the experience! I wrote up some of this in the Project Jupyter case study for the program. It covers some of the high-level challenges that we were trying to think about as we went through this program.

General takeaways

To me, the biggest takeaway from this process was appreciating the need for intentional design around the organization and community of open projects. One of my favorite quotes from this is "be open by design, not open by default". Many projects assume that they are "open" as long as they put their code on github w/ a permissive license. Now I think of open projects more like a dynamic process than a static thing that "is" or "is not" open. In reality open communities are complex, multi-layered communities that require constant and intentional cultivation.

So what does being "intentional" about an open community mean? This is what I think it means:

1. Be explicit about the roles in your community, and be transparent about who fills those roles.
2. Think about the perspectives and trajectories of your community. Why are they interacting with the community? What do they want out of it? What does "success" for them look like? (I think this is what mozilla thinks of as "user stories")
3. Think about the structures that the community has set up to accommodate the user perspectives figured out in 2. Does the project set up clear pathways for people to get more engaged over time? And do these pathways map onto the complexity of the community? E.g., many projects give out merge rights for coders, but often don't think about giving other kinds of titles (or responsibilities) to community members to participate in non-coding ways.
4. Treat the community as an ongoing and organic thing. The tensions, diversity, complexity, and interests of the community changes over time - particularly if the project undergoes some kind of growth or change in its scope. It's not enough to set up a structure and then leave it there - you have to continuously re-visit the current system and optimize it over time.

That said, what are some things that I think we could improve in the Jupyter world? Here are a few ideas:

1. Make the sub-communities that currently exist in jupyter more explicit in terms of governance. Define how these communities can make their own decisions, and when they should interface w/ the broader jupyter project.
2. Come up with specific roles and responsibilities within Jupyter, especially when it comes to non-coding things. For example, I'd love if the "Diversity and inclusion group" were "officially" recognized somewhere on the website. On that note I also think there should be a group whose role is to be stewards over the website.
3. Come up with some more specific design processes for transparent and inclusive decision-making. For example, I really like the way that Rust makes decisions via a distributed Request for Comments process.
4. Come up with explicit "phases" of Jupyter projects so that we can signal to the community what kind of interaction to expect. For example, the Mozilla archetypes of open source document describes some projects that move intentionally quickly at the risk of alienating the developer community ("Rocketship to Mars") vs. those that intentionally slow themselves down in order to be more inclusive, stable, and to start growing a community around it. I'd love if we had a way to signal something like this for Jupyter projects, and have a way to transfer from one project phase to another.
5. Create a Jupyter community growth guide, for people who'd like to spend time helping out the Jupyter world. For example, @ivanov has been doing some really cool things around the idea of an "open studio". I'd love this model to be written down somewhere that another person could replicate it wherever they are. I'd also love to have suggestions for people that have small amounts of money (e.g. $100s to $1000s) that'd like to use it to support Jupyter (e.g. paying for an Outreachy intern, or covering conference travel for a newer jupyter community member).

Those are just a few thoughts :-)

I hope that this issue has been useful or interesting for folks in the Jupyter community! I'd love to see some of the stuff in here get fed back into the organization so that we can keep moving things in a positive direction. This whole thing has made me so much more appreciative of the work that many of you have done or are doing to keep Jupyter a healthy place. We have had plenty of challenges along the way, but I am confident in the direction we're headed.

If anybody wants to chat about any of this stuff, I'd love to do so. There's much more to be done in converting the high-level stuff I talked about here into specific, actionable things that we could do for the project.

See you all on the internet <3
Chris

Week 8: Mountains of Engagement and community communication

This week we covered an interesting way of thinking about how open communities are organized. It's called the "Mountain of Engagement". Briefly, it is a way to structure the many different ways that people can interact with an open community, with a focus on defining the "low-touch" contributors from the "high-touch" contributors. The goal is to make it possible to identify ways that people can be encouraged to act at each level, and to move upwards between levels.

Mountain of Engagement for Binder

I started a short exercise thinking about Mountain of Engagement for one community related to JupyterHub: Binder. @yuvipanda spent a bit of time thinking about the many ways that people interact with the world of Binder, and we started organizing it in this google doc:

https://docs.google.com/document/d/1Ji8nwmh911rjBFQfIG7kQgx1Z13fPHyKTyrGv9U5E58/edit

It is still unfinished! I'll spend some more time thinking about it this week, but if any of you would like to jump in and add your comments, thoughts, etc, then I'd love to see them! I'm hoping this is just the fist time we do an MoE exercise for Jupyter, and that we include as many folks as possible.

The JupyterHub Discourse page

Another thing that has often been a challenge in the Jupyter community is facilitating many different kinds of communication between a diverse community. Some of it is specific and technical, others is generic, non-technical, or more usecase-specific. Moreover, one thing that the OL6 program has focused on is the value that communities can create for themselves, if provided the right channels to do so.

So, with that in mind, we set up an experimental JupyterHub Discourse page:

https://discourse.jupyter.org/

We'll see if this becomes a positive force in the JupyterHub / Binder communities. The goal is for it to encourage more fluid communication bother between "Jupyter core" people and the community as well as amongst community members. If it works well, perhaps it'll be worth generalizing this place to "Jupyter as a whole" rather than just JupyterHub.

Week 6: governance structures and safety

Hey all - a quick update for folks. This week the Mozilla group met again, this time to discuss diversity, inclusion, and safety in the context of open projects and specifically for events. There was a lot of interesting material in there. The Mozilla accessibility notes for mozfest were pretty cool, and it turns out that NUMFocus has a guide to increasing diversity in events.

In addition, I followed up a bit on a previous week's topic and started looking into governance models + community structure for several other open source projects. There's a lot of interesting stuff out there! I even wrote up a short blog post about Rust's governance structure. But it makes me think that perhaps keeping a separate issue for researching governance stuff is a good idea, so I'll do that here: #60

• link to notes

Week 4: value exchanges and community member pathways

It's been two weeks since the last update, so here's a quick update on what we've covered so far. Last week we covered a pretty interesting topic - value exchanges. Here's a link to the full session notes:

• link to notes with group discussions and more links from Mozilla.
• Here are the slides from a section that covers a lot of community interaction topics
• Here's a taxonomy of value exchanges - useful in thinking about why value exchanges are important and how to refine our thinking around them.

Community interactions and value exchanges

One of the main topics covered thus far has been value exchanges. The way I interpret this is that "value" simply means "something that a person gets out of participating in an open project". For open projects to be successful, there needs to be a clear value exchange for both the project community as well as the contributor. For example, say somebody fixes a bug or adds a new feature. The project community benefits from a better tool, and the contributor would receive a shout-out/recognition for their contribution, and maybe a warm fuzzy feeling. Another example: somebody routinely responds to first-time contributors in project repositories. The project community benefits because there's a healthier community churn of contributors, the person responding to issues benefits because the project recognizes their work for the community and they get the experience of growing that community (there's also another value exchange embedded in here for the new contributor as well).

The point is, we need to make sure that there are benefits on both sides of the equation. At first I was a little bit put off by this idea because it felt sort of "transactional". But now I feel like it's just making something explicit ("what is the value you derive from interacting with this community") instead of implicit.

Community member pathways

Tying in with "value exchanges" is the question "what kind of pathways do people take through the Jupyter community?". For example, if you're a developer, user, leader, documenter, learner, what opportunities are there for you to interact with Jupyter? Has Jupyter made these opportunities clear and actionable (and recognized)? Part of this involves some brainstorming about ways to contribute that aren't initially obvious. Thinking about this from the perspective of user/contributor stories, with people of differing skillsets, backgrounds, demographics, etc, is a way to make some of these pathways more explicit and design around them.

Random tidbits

• People from many communities were specifically interested in the topic of "planned leadership churn" in order to avoid burnout and bottlenecking on a single person. I heard that the p5js project tried this as a part of last year's OLF project, maybe worth looking into that!

Week 2: Open roadmaps and a project canvas

This week focused on some high-level conversations around structuring projects so that they have a clear vision and obvious points of contact with the community.

• Weekly meeting notes - with some nice discussion around "examples of open projects" for inspiration.

Open by Design

One of the core mantras of the Mozilla program is to be "Open by Design" rather than "Open by Default". To me, this means that the design of the project and any organization associated with the project has treated the community as a first-class citizen. Most projects assume that if they put their code on GitHub then they are "open". In a sense, yes, but Mozilla would call this "Open by Default". Instead, those projects could take care to craft documentation, community practices, and organizational roles to encourage others to join the project or participate in the community. These are "open by design".

• Here's a page on the Mozilla Open Leadership Framework that talks about some of this stuff

Storytelling

We also had a conversation around storytelling in the community. The takeaway for me was that it's more effective to inspire communities (or newcomers) by showing and recognizing what it means to interact with the community. It's more productive to show people what it means to be successful in an open community rather than telling them what they must do.

At the same time, storytelling is useful to consider in the context of how we interact with each other in the community. Think about a person's trajectory interacting with Jupyter (whether it be a newcomer, core dev, etc) - what kind of valence does it have? Is it a good story? Does it have a moral, or a lesson-learned? How could it have been different to better-support the community? Stories are often "felt" more than "remembered", so consider this in how we structure interactions with our community.

Another takeaway quote from this section for me:

People don’t remember what you say, they remember how you made them feel.

Project structures and planning

We also discussed the importance of being explicit about planning and goals for a project. Oftentimes people want to know what the future of a project looks like in order to decide if / how they can help out. We discussed the importance of structuring this in a clear way as well as making this "plan" available for the community to see. Importantly, this doesn't mean that you're committing to a specific plan or dates, but that you're being explicit and structured about your thinking as a community (in the current moment).

As a start, we put together this canvas, which tries to lay out some of our thinking for this project.

https://drive.google.com/open?id=1d661viUo6QDxRnyNBjaPq05GTs9Y0rrIp4qYzl6Qa-4

TODO

*note - these items aren't actively being worked on anymore, but I'm leaving them here for posterity's sake. We got through most of them, though not all :-) *
This is a (growing and hopefully also shrinking) list of items to write about, think about, brainstorm, etc with Jupyter. I'll try to keep it updated over the weeks with links to issues etc.

• Create a "project canvas" to structure what we'll try to work on over this program (link)
• Update some of the JupyterHub repositories with a "ROADMAP.md" file we keep updated (this will require some conversation w/ the JupyterHub community, issue open about it here jupyterhub/team-compass#70)
• What are common value exchanges in the Jupyter community? What are some implicit (or un-recognized) value exchanges that could be made explicit?
• Think about some common user pathways through the Jupyter community (tied in with user stories)
• Research the structure of other open organizations for how they handle collective decision-making etc.

NOTE: The updates will be in reverse chronological order. So, newest updates up top, oldest updates towards the bottom.

Context

gke.mybinder.org is the largest member of the Binder federation. We have historically run it via credit donations from Google, and have scrambled to find credits from other stakeholders when these credits run out. Credits tend to come in 1-year batches with hard end-dates.

Because of the cyclical nature of credits, it creates a "credit crunch" where old credits may run out, but we have not yet found new credits for the infrastructure. This creates stressful situations where it's unclear how we'll pay for gke.mybinder.org. Most recently this happened in the issues below:

• jupyterhub/mybinder.org-deploy#2138
• jupyterhub/team-compass#430
• jupyterhub/team-compass#463

In these moments, individual stakeholders in the Binder project have stepped up to backstop gke.mybinder.org while we look for more credits, but this is a risky solution that depends on individual actors stepping up, and is a potential source of inequity amongst the Binder team members.

Instead, we should define a process that:

1. Reduces the risk associated with running out of credits on mybinder.org
2. Defines clear responsibilities for who must ensure that more credits are available to run the service

Proposal

As a first step, I propose that we set aside a dedicate account to backstop gke.mybinder.org. This account could be linked to the gke.mybinder.org Billing Account, so that whenever credits ran out, we would begin drawing from this account as a last resort. Our target would be to have at least 6 months of funding in the account at all times, to give us plenty of leeway if we need to find another round of credits or fundraise for it.

Note that most of the time, this funding would not be used - we still aim to power mybinder.org via credit allocations. This is just "gap funding" for when credits happen to run out.

How much cost are we talking about?

Historically, gke.mybinder.org costs around $7,000 per month (so, 6 months of funding would be roughly $42,000). However, we have recently undertaken several cost-saving measures, and believe that this is down to around $4,000 a month. So let's say $24,000 is a low-estimate for 6 months of usage. Ideally, we'd shoot for $50,000 in reserves if the funds were available, to give ourselves some breathing room.

Steps to implement this

I believe that we'd need to take the following steps:

• Decide whether Jupyter wants to commit to this responsibility
• Agree on a backstop amount, and find the source of this funding (potentially fundraising if necessary)
• Define the charter for this funding, and the process around when we begin drawing down from this fund + how we will replenish it if we must draw down the funds.

In working on #69 , I found that the Turing Way CoC had a useful list of unnacceptable behaviors and some consequences:

https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md#22-unacceptable-behaviour

I found this to be a way of making the more abstract ideals of the CoC a little bit more concrete. I also found their list to be generally useful and complete.

What do people think about me copying that section, with minimal changes, from the Turing Way CoC into the Jupyter CoC?

For reference, here is the full text of the section:

2.2 Unacceptable Behaviour

Examples of unacceptable behaviour by Turing Way community members at any project event or platform include:

• written or verbal comments which have the effect of excluding people on the basis of membership of any specific group
• causing someone to fear for their safety, such as through stalking, following, or intimidation
• violent threats or language directed against another person
• the display of sexual or violent images
• unwelcome sexual attention
• nonconsensual or unwelcome physical contact
• sustained disruption of talks, events or communications
• insults or put downs
• sexist, racist, homophobic, transphobic, ableist, or exclusionary jokes
• excessive swearing
• incitement to violence, suicide, or self-harm
• continuing to initiate interaction (including photography or recording) with someone after being asked to stop
• publication of private communication without consent

2.3 Consequences of Unacceptable Behaviour

Participants who are asked to stop any inappropriate behaviour are expected to comply immediately.
This applies to all Turing Way community events and platforms, either online or in-person.
If a participant engages in behaviour that violates this Code of Conduct, any member of the core development team may warn the offender, ask them to leave the event or platform (without refund), or impose any other appropriate sanctions (see the enforcement manual for details).

Many open source communities and projects are migrating to Mastodon right now. As part of that process, several organizations are defining "official" accounts in a Mastodon server, so that others know where is the source of truth for communications from that organization.

Several examples of "official" accounts in Mastodon are provided by @krassowski here:

• https://discourse.jupyter.org/t/official-mastodon-account-s/16688/8?u=choldgraf

Given the high-visibility nature of Jupyter, I think it's important that we provide this source of truth in Mastodon to avoid confusion about where our communications are coming from.

However, there's an open question about which Mastodon server Jupyter should use, there's been some discussion of this in the discourse thread:

• https://discourse.jupyter.org/t/official-mastodon-account-s/16688

Given that we don't yet know if there will be an "official" Python projects server, and given that it is relatively easy to transition to new servers if you wish, I propose we take the following path:

Proposal

• Wait for three weeks to see if an "official" Python or Scientific Python server arises that we can use.
• If it does, then create a projectjupyter@<this-new-server.org> account
• If not, then create an official Jupyter social media account on fosstodon.org (this is the server many other major projects have used)
• Document it as our official Jupyter account, and add a rel="me" link to our home page to this account.

(This came up in the private Steering Council group and we wanted to open this here for public discussion and eventual voting)

Previously, we have been creating individual Gmail addresses for project use. This includes things like a main jupyter email address, a code of conduct email, etc. We have been having a tough time tracking all of these, managing forwarding, managing access, resetting passwords, etc.

NumFOCUS, the parent non-profit of Jupyter, has an organizational Google Workspaces account, with Gmail addresses available under the numfocus.org. This would allow for centralized management of these email addresses and make it easy for us to have email addresses under a single domain (numfocus.org).

I propose that we use the NumFOCUS Gmail Workspace for all of our Gmail accounts. If approved, there would be some follow on actions:

• Catalogue the existing email addresses we have today.
• Generate a list of the new email addresses we would replace them by.
• Create the new email addreses and document who should have access to each of them, where they should be forwarded, etc.
• Identify other downstream services (hosting, domains, etc.) that use those existing email addreses.
• Change those downstream services to use the new addresses.
• Change websites and documentation to point to the new addresses.
• Deprecate (how exactly?) the old addresses.

I am willing to help with this work, but would love a few other folks to help out. Probably makes sense to eventually have a working group for this type of thing.

Hello All,

This follows some conversation that I had at SciPy, as well as some discussion that started on the steering council mailing list but we believe it is important to get this discussion in public.

I heard a lot of good things about our governance policy and our governance documents; at SciPy in particular, but also other event, or even on a day to day basis. In particular you will be happy to know that Matplotlib want to adopt the same governance structure, and is looking to roughly take our documents as is by just replacing Jupyter by Matplotlib:

matplotlib/governance#1

I think though that some wording in the various documents and some details of the governance structure could be improved, mainly to convey better the spirit of the document.

The current governance document require people to have been "involved" in the project for a period of at least a year:

an individual must be a Project Contributor who has produced contributions that are substantial in quality and quantity, and sustained over at least one year

This is a perfectly reasonable requirement to be sure that the candidate have shown a long term interest to the project. I'm concern though that this is in practice biases toward technical contributions. We did explicitly make the language in the governance document vague, in order to include more people:

This will include but is not limited to code, code review, infrastructure work, mailing list and chat participation, community help/building, education and outreach, design work, etc

I think we can do a better job regarding this point by trying to get in the steering council members from various horizons and with often various vision for the project. I think in that long time user of Jupyter like Greg Wilson, Lorena Barba, Doug Blank, could be of great help in the council as they are regular users of the notebook and are in contact with people using the notebook on a day to day basis. I believe people like Gael Varoquaux, have extremely valid critics of the notebook in part because of they have to stay on Old version of the packages and upgrade often leapfrog in many versions. People have a wider-view of the project like Jamie Whitacre and Carol Willing would be extremely helpful as well,...

Thus I would like to try to emphasise the diversity of the steering council.

My personal though, is also that the steering council might be too large (or on the verge of becoming too large), and adds a lot of noise for each of the members. I would like to think about a "restricted board" that could make more non-sensitive decision without the all council approval. This does not prevent the board to request advice from council advisor, that could more technical in specific domain. I think in particular at people like Adrew Gibiansky Haskell), Philipe A. (R) , that have show longterm regular involvement in the project on highly specific technical points.

This leave also the door open to have a rotating board, which is smaller, and that could be picked changed at regular interval in order to relieve some of the board member from yet-another-task. The reduced board size could also likely resolve things more quickly, as it is often hard to get global consensus. How to select this board might also help address on of the other main comment I had related to the following point of the governance:

Potential Council Members are nominated by existing Council members and voted upon by the existing Council after asking if the potential Member is interested and willing to serve in that capacity.

This sounded for many as a selective private club.

I would like to see if we can experiment with asking the community to select members. For example on a 6 month basis, ask for an anonymous (?) proposal of someone who they think have an non-negligible impact on promoting helping with Jupyter.

One other point that I have heard a few time is that despite recognizing that the member of the council are extremely valuable to the project, the nomination process and the 1 year of involvement looks a lot like a reward for seniority ; not that it is, but I can completely see the reasoning from a quick glance at the process. The SageMath project does apparently have a specific distinction for long standing member. I would like to consider this as an option as well as it would clearly distinguish long-term technical and regular involvement from actually being part of the governance. I can also completely see people that would be happy to get a distinctions for being a long standing member, without wanting to be part of the governance.

Thanks