Metric collections have stopped since Dec 1st, you can still tag your repo with the closember tag to see how well you did, and get ready for next year.

Why Closember ?

Closember aims to increase awareness about Open Source maintainer burnout and promote practices to make maintaining open-source less stressful and more enjoyable for everyone. more…

Did you know ?

You can go to https://github.com/issues and https://github.com/pulls to see all the issues/pull-requests you opened. Are those still relevant ? Maybe close a few if not.

Closeboard

Placeholder values : Will be reset to 0 on Nov 1^st when Closember starts.

Remember remember to close a PR in November.

This table tracks the number of Issues and Pull requests that have been closed(or merged) in each of projects during the month of Closember. Issues opened in Closember do not count in an effort to encourage the closing of older issues.

Total Open

Placeholder values : Will be reset to 0 on Nov 1^st when Closember starts.

There is no perfect metric, and we sometimes f et that issues are forgotten on the last page of the issue list. Here is a leader board of who has closed the oldest issues during the month.

Longest open issue

This shows the longest opened issue closed during Closember.

(Note: there is not longest open PR because of GitHub API. Unless you find a way to do it)

Placeholder values : Will be reset to 0 on Nov 1^st when Closember starts.

Those are suggested metrics, they are of course not absolute. Your community should have its own goal, though be careful about the Normalization of deviance. You can also suggest metrics, send us a PR, or open an issue.

Show your support : 42 Supporters

Star our repository to show your support even if your own organizations or projects don't participate Star

JPTIZ

hearot

hameerabbasi

diefans

Carreau

ericdatakelly

willmcgugan

astrojuanlu

jefftriplett

timofurrer

ENM1989

neutrinoceros

czgdp1807

pratikgl

thelittlebug

toonarmycaptain

Jordan-Cottle

joshuacwnewton

dalthviz

ayharano

luizirber

SaranjeetKaur

InessaPawson

mih

smoia

bsipocz

mwcraig

adswa

dcherian

yarikoptic

mvdoc

yochannah

Remi-Gau

jadecci

djhoese

OriolAbril

JessicaS11

martinacantaro

cmarmo

francoisgoupil

Vincent-Maladiere

hturner

Maintainers in Open Source

The Role of a Maintainer in Open-Source is rarely about simply writing more code or getting more Pull-Requests. It is about properly caring, knowing how to say “No” and thinking about long term sustainability.

Having a well-setup process, not too many tasks running at the same time, can be critical for Maintainers cognitive load, and mental health, as well as provide an easier environment for new contributors.

When projects have fewer open pull requests, and well curated issues that are closed when not relevant it is easier to get timely reviews. As a result maintainers more easily avoid duplicate work, have less risk of code conflicts, and have an easier time finding potential duplicate bugs.

Fewer tasks, and less stress also lead to friendlier interactions.

Therefore, we encourage contributions to Closember. Work with your favorite maintainers, on your favorite repositories to decrease the number of opened issues and pull-requests for a more dynamic, better maintained, cleaner, leaner, environment and ecosystem.

We also encourage you to avoid duplicate work by merging similar projects when relevant.

Join us to close issues and PRs

The tables below tracks multiple metrics to help you achieve goals. There are no good, or bad metrics, but it is fun to be able to compare.

Please be careful about project guidelines and whether an issue should be closed, some projects close issues/PR that have not been commented on in a while, some others only close issues when it is resolved and a release has been made. If you are ever in doubt, ask.

Zeno Paradox

… you keep closing them but new ones keep opening. This is why issues or pull-requests opened during November do not count toward the total. This is not meant to disrupt the normal flow of work, but to encourage you to help maintainers take care of older issues and pull-requests.

What should I do?

This is about you first; you need to be in a good mental state in order to help others. Personally I’ll walk in circles for about 2 hours, tidy my desk, remove extra icons for my desktop, and also try to decrease my amount of unread emails. Like can I get under 1000? Another trick is to find a couple of things and click “unsubscribe”, it can be emails, or slack channels or un-follow people on twitter/facebook/instagram.

Once you feel great about yourself go help others. What you just did for yourself here, you can now do for the maintainers of your favorites projects, and make those project better for everyone.

Maintainers: How to get ready:

• Speak with your co-maintainers/contributors, and let them know that you are considering participation. You can send your community links to this page and requests help. You can organise groups that would be responsible for reviewing old issues and seeing if they are still relevant, and setup guidelines on how to proceed during the month of November.

• Tag the repositories you control with the closember topic, they will be listed here automatically soon. If you can’t or don’t want to for some reason, we can hard-code your repository in the list (see https://github.com/openteamsinc/closember/issues/3).

• You can star our repository to show support as well.

• You may want to consider using the GitHub “Triage” role, this will let you give users the ability to open/close issues without giving push rights. See this page on GitHub docs that list permissions of each group

How can I help other?

Great question! You often do not need to know how to code to contribute to Closember! For any project you contribute to, make sure to check their guidelines, and avoid eager closing of issues/PRs if that’s not the desire of the maintainers. The following guide is intended to be adapted to your skills and skills that can be of use for projects.

• find your favorite project, look at an old opened issue. Can you reproduce it ? Is it still relevant? If not, leave a nice comment, like :
  • “I tried to reproduce this issue, but on the latest released version it does not seem to be a problem anymore”.
  • “This has actually been fixed by XXXX”
  • “I think that this was an issues back in 2003, but no one uses ie6 anymore, I believe this can be closed.”.

It will be less work for the maintainers, and they’ll close the issue for you.

• You can find the list of all issues you have opened at https://github.com/issues, do the same as above but you can close your own issues too.

• Head to https://github.com/pulls, this has all the pull-requests that you have submitted

• Are they still relevant ?
• Close them if not, think about finishing them otherwise.

• Maybe at least think about rebasing them and git push --force-with-lease to make sure the test passes on the latest versions.

• Finish the Pull-Request of someone else: Many drive by contributors start pull-request but do not finish them. Maybe you can take over? Once your version of the code is merged suggest that the old pull-request to be closed.

How to be listed on this leader-board ?

Add the closember topic to your repositories. Next time the site is updated you’ll be listed.

Why is the score not changing ?

GitHub requests are cached for a few minutes, maybe 1 maybe 10, maybe 60, depend on my mood, or how much traffic we get. It should update soon. But please relax. It’s not a sprint, it’s a marathon.

Show me this website code

https://github.com/openteamsinc/closember – please come close issues.

I closed all my issues / I really want to code…

Ok, fine, you want an excuse to write some code. Still you can do things the make maintainer life easier. A couple pet peeves of mine.

• Add Version number to your deprecation warnings, when I see a deprecation message I want to know since which version it is deprecated and what’s the replacement without having to go dive in the docs.
• Turn your deprecation warnings into error in your test suite, and make sure you are not using (when possible), deprecated functionalities.
• Bump your minimal requirements for old libraries when you can.
• Knows more than one small project doing almost the same things ? Try to get maintainers to merge codebases / collaborate.
• Cleanup your git stale branches,
• Delete forks of repositories you are not contributing to.
• create a system-wide .gitignore to not add *.un~ and .DS_Store to every .gitignore project you contribute to.

I want to lean more about Open-Source

While we haven’t read it yet, we recommend Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal

Do I get a Lousy T-Shirt ?

Open-teams, FairOSS and Quansight are working on this, and how we can sponsors this better. Likely not this year, but we’ll see for next. It is also a tough problem as not everyone can close any issue, so come talk to us if you want to find a way for user to claim having helped and maintainers to validate those claims.

Partners

Closember is currently sponsored by Quansight, FairOSS and OpenTeams.

F.A.Q. with creator

• Why did you create Closember ?
• It’s something I have wanted to do for some time. I regularly participate to hacktoberfest both as a user and maintainer. As a maintainer it can be a deluge of PRs that can be tough to deal with. As a user, large number of PRs can be demotivating.
• Can you extend on what you mean with dealing will pull-requests ?
• Yes, even when you receive a well-meaning pull-request for a feature or bug-fix you want, those usually need some polishing to adapt to the code guidelines, and get tests and documentation added. Many of those contributions by “drive by” contributors are often unfinished, a bit like someone giving you flour, eggs, sugar, and a cake recipe for your birthday.
• Can you expand on the demotivation you face as a user with many PRs?
• I occasionally contribute to repositories I’m not familiar with. Some of those have more than a thousand PRs opened. It is hard to be confident that one more PR, even perfect, will be noticed by maintainers, it’s also unclear whether someone is already doing the work, or if my work will conflict with someone else. I often have to reach out personally to other maintainers – when I know them personally – to get noticed. This is definitely something which can be difficult for a new contributor or less privileged people.
• Anything else ? Chris pointed out that https://www.volunteeramnestyday.net/ was also a good resource to look at.

Comments

Comments on the Following GitHub Issue will appear below.