Project maintenance and development

[ssbarnea]

I first want to thank @adrienverge for writing the yamllint as this proved to be very useful tool for assuring style consistency and preventing various common bugs. I used that for many years and introduced it to many projects.

Still, recently I realized that many open-source projects that depend on a single person can prove to be a serious liability for anyone that relies on them. I saw all kind of problems, from maintainer disappearing, going rogue, domain expiring, CI/CD getting broken and not fixed for long time, failure or very long delays in reviewing contributions or failure to make a new release in time.

Can we implement some measures to assure that the project itself would not be affected by single-point of failures?

I am thinking at stuff like:

• multiple cores
• multiple pypi maintainers
• having release made using CI/CD pipeline instead of manual
• considering hosting the project under an umbrella organization like https://github.com/yaml ?

[adrienverge]

I first want to thank @adrienverge for writing the yamllint as this proved to be very useful tool for assuring style consistency and preventing various common bugs. I used that for many years and introduced it to many projects.

You're welcome!

Still, recently I realized that many open-source projects that depend on a single person can prove to be a serious liability for anyone that relies on them. I saw all kind of problems, from maintainer disappearing, going rogue, domain expiring, CI/CD getting broken and not fixed for long time, failure or very long delays in reviewing contributions or failure to make a new release in time.

I've seen that too.

I don't think yamllint suffers from this problem, I read every issue and pull request, answer when it's relevant, and (correct me if I'm wrong) response time is decent. I don't think an umbrella organization would help.

Everyone is invited to contribute, but also to help maintaining. I would love if you (meaning: anyone, not only @ssbarnea) reviewed pull requests before I do. Currently this is not the case.

About a CI/CD pipeline, this is a good idea. Do you want to help contributing this?

[sandstrom]

@adrienverge Thanks for an awesome project! 🏅

This is an excellent and well maintained repo. But since there are a few outstanding issues, one may falsely get the impression that it isn't.

One thing you could do is to close issues more aggressively. For example:

• If issue opener doesn't respond within 30 days, close issue.
• If the issue is really a question, refer to Github discussions (you must enable first) and close it.
• For old issues, close them and ask people to try on latest master, and ask to have issue reopened if it's still a problem.

You could use canned replies (built into Github) for these, to save time.

For example, it could look like this:

I'm doing some issue gardening 🌱🌿 🌷 and came upon this issue. Since it's quite old I just wanted to ask if this is still relevant? If it isn't, maybe we can close this issue?

By closing some old issues we reduce the list of open issues to a more manageable set.

Or like this:

Is this an issue with the code itself, or a general question? For general questions Stackoverflow is better than Github.

I'm closing this now, but I'm willing to reopen if there is an actual code issue. If so, steps to reproduce (and ideally a failing test-case) is a good start.

[adrienverge]

Hey @sandstrom, thanks for the pragmatic and action-oriented advice :+1:

I agree some issues could be closed. However, I think most of them are relevant and "not resolved", even when nothing can be done inside yamllint itself. Hence, they look better open to me, so users can find them more easily. I know some projects use bots to automatically close issues, but it doesn't solve anything, and even causes users to open new ones for the same problems.