In commit 88b5477, which doesn't look like a mistake. Why? I don't see a reason to keep private configuration in the repository. vscode allows to store workspaces outside of a repository.

• Logos
• Meeting notes
• Governance documents

We can also highlight the CoC and license in the readme.

As documented in BEP 4 here:

The minimum criteria for joining @bokeh/dev is acceptance of two substantive pull requests to a Bokeh project. Anyone meeting this threshold who also agrees to join, may be added to @bokeh/dev by any member of the core team, without discussion. Generally, a core team member will try to extend an invitations when new contributors first become active, however users may also self-nominate themselves to any core team member.

It'll be nice to have a bot that identifies contributors who have 2 PRs merged (PRs made in reasonably quick succession) and invites them to join @bokeh-dev.

Consider moving the BEPs documents here, it has two key advantages over the wiki:

• we can have a clear commit history that tracks updates (we do it manually in the wiki)
• the documents will be arguably easier to find/search

Once #6 is accomplished, I think BEP 7: Decision Making needs to be fleshed out a bit more. It states simply:

Otherwise, a vote will be taken among all the team members.

But does not go into any actual detail about that process. E.g. it does not specify what should happen

• in the event of a tie
• in the event of abstentions (i.e. what constitutes a sufficient quorum)

@bryevdv Somewhere within Bokeh's documentation, wiki, repositories, or elsewhere, please start a listing of little project ideas for Google Summer of Code/Outreachy/LFX interns.

The first one on the list: creating a JOSS item for Bokeh, to get a DOI for researchers to cite.

We currently have a half-dozen archived repos:

Can some of these be deleted? I'd like newcomers to the Bokeh org to be confronted with as little irrelevant and useless informatio as possible. Offhand I personally think these could definitely de deleted:

• blog.bokeh.org (useless, all material copied over to medium at this point)
• bokehplots.com (useless, nothing relevant or useful for most of a decade here)
• bkcharts (completely irrelevant today)

It seems like there may be others archived soon (e.g. RBokeh and possibly some vendored dependencies). Would it be reasonable to make a bokeh-attic GH Org to move old archived repositories to? That would include vendored dependencies archived more than two minor releases ago. since we would never expect to make any more point releases on those branches ever. In the highly, extremely unlikely event that we did need them, the repos would technically still be accessible with some effort.

cc @bokeh/core

Currently, we have a [email protected] email where community members can report CoC-related issues. Since this is a publicly listed email, we get a LOT of spam emails that need managing.

While discussing the recent NF CoC updates, @bryevdv and I (current CoC committee members) felt it'll be more efficient to use a form for CoC reporting. We can use Question Scout (which we also use for Slack invites) or regular Google forms.