mochajs / admin Goto Github PK

Hey Mocha team!

I had a great chat with @boneskull at the OpenJS Collaborators Summit about open source, funding (see #5), and Tidelift—where I just started working.

I’ve been looking through our list of projects that have funding available and noticed Mocha has almost $700 per month that can be claimed by your core contributors. We’d love to get some of the team signed up so we can start paying you this money. It can be claimed by one maintainer that wants to be responsible for Tidelift tasks or you can split it amongst multiple maintainers. If you are looking to split it up, I highly recommend checking out pytest’s Tidelift guidelines for their maintainers.

The high-level overview of Tidelift is that we sell a “managed open source” subscription to companies and pay that money out to maintainers. We use their dependency trees to determine which packages are depended upon and, therefore, should get the funds. You can read more about Tidelift’s subscription service on our site.

The tasks we ask you to perform are things that most maintainers already do (such as provide release notes, validate the license of a package, and monitor and alert for security vulnerabilities), but you can find the specific details in this blog post by @kszu.

Please let me know what you think! I’m happy to answer any other questions you might have. 😄

Thanks for all your hard work,
-Blaine

So, we have some money. But mostly we're not using it. Let's figure out how to do that.

Here's Gulp's expense policy, for example: https://github.com/gulpjs/gulp/blob/master/EXPENSE_POLICY.md

Gulp's seems OK, but I think it can be improved upon for us. Is anyone interested in creating bug bounties?

The main thing I like is this: To be paid for work, the maintainer must create a proposal first. To accept a proposal, we'll need to define what a "quorum" looks like, because we can't expect every maintainer to weigh in on every proposal.

cc @mochajs/core

To support "LTS"--or long-running releases--we will need to make some development workflow changes.

In terms of a branching strategy, I'm thinking the most reasonable approach would be trunk-based development, which I had experimented with before without knowing what it was called. Node.js uses something very similar to this.

In a nutshell:

• all development work is done targeting master (except in the case that the bug cannot be reproduced in master; it then must happen on release branches)
• each LTS release (e.g., each major or even-numbered majors) branches from master
• bug fixes, features, etc. are cherry-picked from master into the release branch
• releases are tagged from the release branches, not master
• "feature" branches exist how we've been doing them--no change here. these are any short-lived branches to be rebased onto master and merged via a PR. note that this includes bug fixes, "chores"--pretty much anything.
• in the case that work must be done against a release branch, a PR should target that branch, and cherry-picked from release into master, if it makes sense.
• at no point is a release branch ever merged back into master.

In addition to whatever we're going to get from users reporting bugs against multiple release lines, this is the overhead we're looking at for LTS releases. There are some tools available which we can either use outright or adapt for our uses (from the Node.js project), but we may need a purpose-built solution. For example, it'd maybe make sense to automatically attempt cherry-picking of new changesets in master into the active release branches.

(AFAIK, cherry-picking is used because otherwise each changeset in master would create an extra merge commit when pulled into an active release branch.)

A noted headache is cross-referencing changesets with their original PRs (due to the loss of context created when a changeset is cherry-picked instead of merged). It becomes critical to link to the PR number somewhere in the commit message. Of course, you can't add the PR to the commit message when you create a changeset, so the commit message must be amended at time-of-merge. Node.js also has tooling (and a convention) around this.

Another unconventional way to tackle this is to literally snapshot the codebase for each release line and stuff it in some subdirectory. I'm pretty sure I didn't just dream this up. Anyway, I don't think the tooling's there to support this sort of thing, though at its core, it sounds similar to a monorepo. The major challenge would be to coordinate patch application across multiple directories, assuming something like Lerna could manage the rest of it. While the above branching solution is non-trivial, I still don't see a clear advantage; both will require tooling.

cc @mochajs/core

Hey all

A first video call with @boneskull and myself (at the OpenJS collab summit) proved to be incredibly productive. We both felt it would be worth trying to put together a semi(?) regular meeting with all @mochajs/core members.

I don't think we should force anyone to attend, but definitely encourage everyone in the core team.

However as you can see from below, with the variation of time zones it might be tricky to get everyone together at the same time.

Mochajs/core team locations + time zones

These are the locations and timezones I am aware of, if any are missed or an incorrect timezone, please flag.

• Washington, USA (UTC/GMT -4)
• London, UK (UTC/GMT +1)
• Basel, Switzerland (UTC/GMT +2)
• Netherlands (UTC/GMT +2)
• Copenhagen, Denmark (UTC/GMT +2)
• Israel (UTC/GMT +3)
• Seoul, South Korea (UTC/GMT +9)

Timezone groups

Seem to be 3 main groups of timezones from what I can see.

1. UTC/GMT - 4
2. UTC/GMT + 2 (ish)
3. UTC/GMT + 9

Daylight savings

Worth noting that some locations are in daylight savings, which I do not believe applies to all of them. So any arrangements might not work permanently.

Scenarios with all timezones

• Having a 8am call in Washington I believe is 9pm in Seoul.
• Having a 7am call in Seoul is 6pm in Washington, but midnight in Copenhagen and 1am in Israel.

Some ideas

A. Duplicate meetings

• first a meeting with timezone groups 1+2, then a meeting with timezones group 2+3.
• very prescriptive and likely only useful once we have proven value from any meetings.
• duplicate discussions in separate places is bad.

B. Have a meeting once but hold it late/early for someone

• if the late/early person is comfortable, then why not.
• having the entire team together could prove incredibly useful

C. Have an agenda-based meeting once, not all members attend each time

• Similar to A except those in a certain time zone group will not attend a given meet
• this could work if we organise agendas around who is available when (e.g someone in timezone group 2 has ownership of agenda X, so ensure thats covered in that meet)
• would take several meetings to cover everything, but that seems fine
• on the bad side: there might be several members who never manage to speak on a call, but considering there isn't anything in place right now perhaps thats fine

D. JFDI

• someone creates a "Doodle" (or something similar) with a time set, and ppl decide themselves whether they can/want to attend.
• ideally get an attendance of at least 3
• report back after on how it went and if others want to try another one.

Anyway those are my ideas, probably not great but wondering what other people are thinking.

Thanks

Context

As part of the new OpenJS Foundation's bylaws, the Cross Project Council (CPC) has been chartered to serve as the primary governing body for programs and regular support of Foundation projects. For example, it will be responsible for things like infrastructure, travel assistance, CoC support, accepting new projects into the foundation, and mentorship programs to name a few. It will also be responsible for electing board representative(s) to the OpenJS Foundation board of directors.

Any interested person from our project communities can attend CPC meetings and volunteer to participate in tasks. For most programs, the CPC is expected to operate on the consensus of OpenJS Foundation project members. Issues that require a vote - namely the election of Board representatives and accepting a new project - will be memorialized by a voting CPC membership comprised of up to 2 representatives from Impact level projects and 2 representatives from Growth and At-Large stages.

If you'd like more info/context on the governance of the OpenJS Foundation, please let me know or follow this repo. The main point I hope you take away is that the foundation is to be run by and for the projects, and to do that we need participants from the project community.

Request

As a Growth stage project, Mocha is strongly encouraged to send representatives to participate in CPC meetings, to advise on programs and support that will be helpful to it, and to nominate someone from the project community to serve in a voting capacity.

We anticipate having our first 'official' CPC meeting on May 30 or 31 at the Collaborator Summit in Berlin (sidebar, you should come!). In the interim, we would love for Mocha project members to participate in the Bootstrap CPC meetings which are currently held on Mondays (watch this repo for meeting details).

If this is not the correct forum to raise this, please let me know and I will close the issue and post it in the preferred channel. Note that I'm posting essentially the same message to all OpenJS Foundation project repos, because I want to get the word out and make sure we all have the same information.

your pal,
Jory

The OpenJS marketing dept wants to interview project maintainers to get a better feel for how to promote the projects.

Who might be interested? cc @mochajs/core @jorydotcom

_{Sent with GitHawk}

I began this in the Gitter chat, but I think this is maybe a better place for discussion--unless you'd rather take it private.

A few of our "sponsors" are rather dubious companies that are likely looking for a cheap way to optimize SEO.

I don't love this. Here are some ideas:

1. Increase the cost of displaying a logo on the site
2. Manually approve sponsors by some vetting process. Sponsors that are not approved will get refunds.
3. Write up a policy regarding what we'll link to and what we won't. For example, there's nothing stopping a neo-nazi site from sponsoring us and causing a logo and link to be displayed.
4. A policy that we should add, regardless: we reserve the right to remove a logo from our page at any time for any reason.

Some of this may be good to discuss with OC as they are more experienced with these issues (than I am, at least).

cc @Munter @juergba @outsideris @craigtaub

An issue has been created for OpenJSF "onboarding." Per that issue, we need to take care of a few tasks for the Foundation. Some items are currently blocked, because work needs to happen on the OJSF side before we can proceed.

As of this writing, this is what we can move forward on:

• Adopt the OpenJSF Code of Conduct - this involves copying and pasting into our CODE_OF_CONDUCT.md
• Add OpenJSF logo to our site - the OJSF may have a specific image and/or guidance on where this should be placed, but failing that, we can just add one.
• Determine project points-of-contact for use by the Foundation. If you (a Mocha maintainer) would like to be the "official" point-of-contact for one or more of the following areas: a) marketing & social media, b) technical leadership, or c) project governance, please let it be known. Otherwise I'll just deal with this.
• Update disclaimer on OpenCollective site to read "OpenJS Foundation" instead of "JS Foundation" (I can do this)

As further tasks become unblocked, we can address those.

What our goals are as a Growth-stage project, and indeed how we even go about determining them, is to-be-determined. All I know at this point is that it will involve working with the CPC in some capacity. As a voting member of the CPC, I will also have a say in what that process looks like--so if you have any ideas on how to best go about this, I can propose them to the CPC when it's appropriate.

Wanted to share this FYI out to the Mocha community to let ya’ll know that the OpenJS Foundation has opened its call for speakers for the upcoming virtual OpenJS World event on 9 June 2021. We would love to make sure the project is well represented in the conference content! If anyone is interested and has more questions, wants help writing an abstract, or wants to get involved with the CFP Reviews, email me at jory @ thestoryofjory dot com or ping me in Slack.

We’d also love your help getting the word out about the event - if you’d be up to putting a link or banner on the project website, tweeting from your project account, etc. we would be very grateful!

Hi Mocha Community 🤗

I've been asked to help make sure that all the OpenJS Foundation project communities are aware that the deadline for our OpenJS Conference Call for Proposals has been extended through Feb. 28. Previously, this event was called 'Node + JS Interactive' and it leaned heavily toward Node.js. We're hoping to have a wider range of sessions about all the OpenJS Foundation projects, so we'd love to see presentations about Mocha!

I also wanted to make sure you're aware of the Collaborator's Summit, an event focused on project maintainers, collaborators & contributors. The goal for the collab summit is to provide opportunities for face-to-face working sessions within a single project or across multiple projects. So if you wanted to get your core team together you could do that, or if you want to have a session for new contributors to your project, or if you wanted to work across multiple OpenJS Foundation projects on issues like accessibility, privacy, security, modules, etc. you could do that too. If you're interested in securing session space at the collab summit, please ping me here, reach out on slack or twitter, or open an issue on the /summit repo.

The OpenJS World conference is June 23-24 and Collaborator's Summit is June 25-26 in Austin, TX. These are ticketed events, but members of OpenJS Foundation project communities are eligible for Travel Fund assistance. If you have questions or would like to find out more, please chime in on our /summit repo.

as always, let me know how I can help <3
Jory Burson
OpenJS Foundation Community Manager

Hi, the existing JSF CLA bot is no longer working. I can replace it with EasyCLA, but will need owner access to enable the new app and disable the existing webhooks. Thank you!

some time ago we discussed (purchasing) a site redesign and rebranding. I think we should take steps to move forward with this; we can use the OJSF's resources to get a vetted contractor to work on the project.

We need to answer a couple questions first.

1. What is our budget?
2. What will be the scope of the work?

I'll give my opinion:

1. Budget: we have ~40k USD banked as of this writing. I do not know what is reasonable for a redesign of our magnitude, but I would not want to spend all of it. It's also difficult for me to justify spending a huge sum on something that is, in my mind, wanted but not needed not critical. Just throwing a number out there: maybe 10k?
2. Scope: Ideally, we would have someone redesign and rebrand and implement everything so we don't need to lift a finger. But that's not going to happen; someone would need to integrate this into 11ty and the JsDoc template engine. This may be something we want to pay for, but perhaps integration is not the same contractor. anyway, I'd like to see:
   • A new logo, alternate and text mark
   • A design system: widgets, interactions, styles, and/or components that we can use
   • A site layout: our site is split into two main areas; a very large landing page containing end-user docs, and another section for API docs (which is many pages). I'd like everything to be more tightly integrated, organized, and easily searched, but I would like to abandon the our "huge single page" concept. Splitting things up should help readers focus on finding the information they need while ignoring what they do not.
   • Deliverables would be in some format which we can easily export into images, styles, tags/components, SVGs, etc, such as a Sketch file. Of these, I'm unsure about styles (CSS) and markup: does it need to be hand-written?

Regarding the file format, another possibility may be Figma, but I'm unfamiliar with it. Sketch is not free, so we may want to purchase ourselves licenses (I already have a license) if we wish to work with it.

I suggest we can talk about implementation in a separate discussion; again, I think it makes sense to pay for this, but it may need to be a separate project. Please let me know if you disagree, but IMO it will be difficult to find a single person to do the design work and a complete implementation.

Hopefully you can respond sometime this weekend, as I'd like to get going on this early next week.

cc @mochajs/core @jorydotcom

Hi all! In an effort to make sure we're fully getting the word out to OpenJS Foundation project communities about the collaborator summit, I'm posting the following message on main or admin repos:

This year, the Node Collaborator summit is opening up to include and welcome all former JS Foundation projects. The Collaborator summit is a space where projects and working groups within projects have the dedicated time and space to get together and get work done. We will have project-specific meetings, cross-project meetings on issues like security and standards, and of course meetings to discuss new programs and patterns for the new CPC.

The event will be in Berlin on May 30-31st at the Courtyard Marriott City Center. It is free to register with the password 'collabsummit.' We are also inviting all projects/attendees to suggest meetings and sessions via our CFP - these are not conference talks, but rather collaborative conversations or meetings you would like to hold with your peers. We ask that you register in advance so that we can allocate meeting room space and resources, and so that we can publish where conversations are scheduled in the day or two leading up to the event.

Links:

• Session Proposals
• Registration (password is collabsummit)
• Information on how to apply for the Travel Fund
• Summit Planning Repo

unless we have a reason to keep this private, let's open it up. just wanted to keep it private until others can weigh in. cc @mochajs/core