Looking Back on Community Day for 2024

For just over a year now, the Engineering team at Chocolatey have been getting on board with doing regular Community Days. So, with all that time under our belt, let’s talk about 2024!

What’s a Community Day?

As I’m sure everyone knows, many of our products and community projects are open source, with repositories on GitHub. Part of our open source commitment is to give back to the community we’re a part of, as well as acknowledge and give proper attention to the community contributions in our own repositories. This is one way that we try to do that.

Community Day is where we set aside time to engage with other open source projects. This can be triaging issues and handling code contributions, or pull requests on our open source repositories, picking up outstanding issues that may not otherwise get prioritised, and at least some of the time engaging with the wider community by contributing to other open source repositories.

Where It All Started

This idea started out as some conversations with a friend in the community who was working for Puppet at the time, Mikey Lombardi (GitHub). He told me about how in order to help keep awareness on the large number of open source repositories that they had to manage, they allocated a day every week to work on the community aspect of their open source repositories. This sounded like a pretty good idea and also a good way to help team members engage with the open source projects more. Additionally, it avoids the problem we often see with many companies where team members are mostly working on non-public projects and the wider community rarely sees team engagement and input on their own open source repositories.

In talking with him, he raised the following excellent points as to why implementing a Community Day is a worthwhile endeavour, even though on paper it might first look like it takes time away from prioritised work:

• The team already had obligations to maintain the open source repositories, but time was otherwise not specifically allocated to spend on issue triage, reviewing code contributions, and so on.
• If team members are spending a decent amount of time trying to maintain the open source repositories, this can result in a lot of context switching, where they would be in the middle of other work and have to triage a new issue or find some time to review a code contribution or pull request, which always wound up taking a lot of extra time to just juggle the different work contexts constantly.
• Allocating specific days as Community Day (for them, it was every Monday) meant they could focus more on planned and prioritised work without needing to worry about interruptions; reviewing code contributions, issue triage, and so on were all banished with that can wait until Monday, and the consistent time allocation there allowed them to focus better on both aspects of their work, with much less context switching getting in the way.
  • Additionally, having all team members agree on the same day ensured no team members were held up in either the open source or planned and prioritised work by other team members being assigned to a different context.
• If you aren’t actively maintaining repositories and reducing the friction for open source development and community contributions, you don’t really have an open source project; it could just as well be “public source”. If nobody can really contribute because the barrier to entry remains too high, or the team’s focus is never on issues or pull requests from the community, from a functional standpoint it doesn’t really make sense to call it open source in a lot of ways.

After looking over some of their methods for approaching Community Day and trying to work out what might make sense for Chocolatey, I talked it over with the team, and we got the green-light to allocate some time for Community Day on a regular basis.

What Does That Look Like For Chocolatey?

When we first started, we reserved just one day per quarter for Community Day. A sort of trial run at first, to see how it could work for us.

After a handful of Community Days, we’ve started to look at doing things more frequently. At present, we’re planning for two community days per quarter (one every six weeks or so), with every other Community Day being flagged as explicitly non-Chocolatey days. In other words, we spend half of our Community Days primarily focusing on handling our own open source projects, dealing with triaging issues and reviewing and helping get pull requests over the line, picking up issues and resolving them, and all around working to lower the barrier for open source contributors to be more readily able to contribute to our projects. The other half, we spend focusing on the wider open source ecosystem and helping out and contributing where we can.

For example, Chocolatey CLI depends on PowerShell and .NET, many of our websites rely on various TypeScript libraries, and plenty of the tooling we interact with on a regular basis is also open source. Ultimately, participating in and contributing back to the community whenever and wherever we can, benefits us as well as everyone else in our open source ecosystem.

Somewhat recently, other teams outside the core Engineering team have started to join in on Community Day when they are able to, as well.

Impact

We keep track of issues and pull requests actioned for Community Day, as well as the amount of team participation we’re able to commit to it on a given Community Day, so we can better evaluate what our approximate impact is.

We had a total of 8 Community Days across 2024, from February to December. In that time, we had an average team participation rate of 75% (not counting folks who were out of office at the time).

In general, we record actions for a given pull request or issue. This may include:

• Issue triage:
  • Adjusting issue labels.
  • Responding to issues.
  • Opening or closing an issue.
• Pull requests:
  • Opening or otherwise directly contributing to a pull request.
  • Responding to and/or reviewing a pull request.
  • Merging or closing a pull request.

In 2024, we recorded a total of 297 contributions across all repositories the team worked in, with an average of 8 repositories being worked on during any given Community Day (averaging around 5 Chocolatey-owned repositories and 3 non-Chocolatey-owned repositories). This breaks down into a total of 121 contributions to pull requests, and 80 contributions to issues.

For those of you who like tables, the full breakdown for 2024 looks like this:

Month	Contributions	Pull Requests Actioned	Issues Actioned	Repositories	Team Participation
February	12	8	4	6	71%
March	43	27	16	11	71%
May	52	32	20	7	63%
June	72	44	28	12	86%
July	9	3	6	5	50%
September	20	18	2	7	57%
October	16	10	6	6	100%
December	73	49	24	13	100%

Future

We have steadily worked towards more Community Day contributions and more frequent Community Days as we’ve moved forward; we hope to continue that trend and continue to be able to contribute to our open source community. It may not make sense for us to take things as far as the Puppet folks did, focusing on the community for one day out of every week, but we will continue to evaluate that as we monitor our progress on future Community Days.