Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/pi0/tired-maintainer
🗒️ Notes from a tired maintainer
https://github.com/pi0/tired-maintainer
Last synced: 3 days ago
JSON representation
🗒️ Notes from a tired maintainer
- Host: GitHub
- URL: https://github.com/pi0/tired-maintainer
- Owner: pi0
- Created: 2024-01-23T12:54:14.000Z (11 months ago)
- Default Branch: main
- Last Pushed: 2024-01-23T17:11:13.000Z (11 months ago)
- Last Synced: 2024-10-22T20:33:05.394Z (about 2 months ago)
- Homepage:
- Size: 14.6 KB
- Stars: 322
- Watchers: 4
- Forks: 4
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- my-awesome - pi0/tired-maintainer - 01 star:0.3k fork:0.0k 🗒️ Notes from a tired maintainer (Others)
README
# Notes from a tired maintainer
Hi. You might have come across this text either because you found it somehow or with a link, perhaps in a closed Pull-Request (PR) Issue or a chat. If you are coming from a closed issue or PR, before everything THANK YOU for your contributions and help, i do appreciate that ❤️
The thing is, maintaining multiple open-source projects is not as easy as you might imagine. As a full-time open-source maintainer, I roughly receive more than 200 notifications every 12 hours plus random messages and all are expected to be responded to. They often come from completely different people with different contexts, skill levels, priorities concerns, and so on.
I understand that you face issues that are important enough for you to come to GitHub and attempt to report to fix them. And I know that you might:
- Want a feature to be landed
- Want a bug to be resolved
- Want your PR to be reviewed or released
- Want to have updates and followups for something
- Want to contribute and waiting for the maintainer’s updateAbove, are the responsibilities of the maintainers of course but we have a limited capacity. Please understand that your request while could be undoubtedly super important for you, is not the only one to be addressed. Sometimes scope of an issue that seems small to you is much higher than you imagine and even for explaining it **costs time and focus**.
## Context Switch is EXPENSIVE (for humans and also machines)
I suggest reading [managing the chaos of context switching](https://leaddev.com/process/managing-chaos-context-switching) article by [Addy Osmani](**https://twitter.com/addyosmani) to grasp some context.
Sometimes you might think answering or fixing something takes only a couple of minutes. I understand and want to answer you as soon as possible but this cost me significantly and kills my daily productivity and focus if have to do this for your request. Everyone's needs are important to me and I need to prioritize based on common sense and real merits.
## This PR looks good to me (or tell me what to do)
You or someone else might have already gone ahead and attempted to propose an enhancement or fix and you see the PR which looks good overall to you still pending. Even the maintainer or others (while they really shouldn’t!) might have approved the PR partially or fully. And you see it is still not merged. Here are some possible reasons for it:
- The code quality is not acceptable enough and the maintainer is trying to be “polite” and not discouraging the author
- The PR while addressing one specific thing, is not compatible with the whole project's goals
- The PR needs more thorough testing and extended validation
- The maintainer needs to “Think” about the changes
- The maintainer is simply busy with other prioritiesIn all cases, please BE PATIENT. Be sure that maintainers love nothing more than triaging PRs and moving them forward. Please understand that making decisions in a project is not as easy as you might think. Most of the time there is more context that you might be less aware of.
Finally, If something is critical for you and you believe you can accept these changes at your / your user's risk, you can use solutions like [patch-package](https://www.npmjs.com/package/patch-package) to manually apply them.
## I want to contribute tell me what to do
That is awesome! Nothing is feeling better than having contributions coming to OSS projects.
When I feel a task can accept contributions, I will tend to provide more details as much as possible and as time allows. If you see an issue like this, you are more than welcome to help but please make sure to follow those comments strictly and if disagree, discuss before attempting the changes. If there is no explicit answer from the maintainer, please remain patient and also if the Issue is explicitly not open to contributions, it means it is simply not!
Please understand that contributions always require two collaborative sides. Otherwise, while you might be aiming for something good and willing to help, you might slow things down as a result.
Collaboration only makes sense when the cost is **≤** time cost by the author to address.
## So I will ping you as much as I can
Please don't. It does not help and can lead to finally your request being intentionally delayed, ignored, marked as spam, or closed. But always don't assume your request is delayed intentionally, by default it certainly is not delayed!
## So how can I help
Please be patient and understanding about how [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software) works.
Please try to give better context to the maintainers when communicating:
- Why something is important and needs to be prioritized
- Why do you think something should be done in a specific way?Finally, if you want to contribute to the code or follow up on a PR, please align with the maintainer to minimize the collaboration cost. Please keep your PRs limited to one clear fix also, respecting project conventions and code style.
## Final notes
Coming from an already delayed issue or PR to these notes is probably not pleasant (nor for me) but unless there is not a mutual awareness of how open source works and what is like to be a maintainer, we cannot make things better, together.