Ask HN: How do you keep your stable GitHub repo active? | Hacker News Reader

Ask HN: How do you keep your stable GitHub repo active?

7 pointsbojo5 comments

Perceived Problem: People glance at a repo and see that it hasn't been updated in several months. They decide it is not actively maintained and either find a similar project that has been updated recently, or use the one they found with the worry the maintainer might not ever get back to them if they find a bug or submit a PR.

Example: I maintain a small repo which doesn't require many updates since the API is small and stable. The last update was 5 months ago. I am happy to see the random person star the project, but I don't want future people to skip over it because it has no update activity.

What does everyone do to show project activity? Artificially update the README?

I really want a "check in" button I can display in the project README which basically says "yup, the maintainer has actively been here!", assuring me that a seemingly unmaintained project is in a stable state and being watched over.

If your README states the software is complete, stable, and has all required features implemented, no one should expect updates. Vanity metrics, like artificial activity, would do more harm than good. One of the problems with "social coding" environments like github is people tend to be influenced by the wrong things, like vanity metrics, rather than the right things, like useful code. The only way to win that game is to refuse to play.

Yes I would agree. A simple, real note on your README should suffice. You can't fake this stuff!

This may not apply to your language, but some projects could be maintained by making sure the newest compilers don't throw warnings. In my experience every once in a while when I try a new version of clang on my project, there will be some new warning showing up due to improved diagnostics. Even if not, grab some new tool and check your source - then say you've done it. Some ideas: (for a C project)

- warnings under GCC, clang

- valgrind (commit suppressions of needed, note there are no issues left)

- clang static analyser

- fuzz inputs, commit a note about what was tested

- does it already compile under Linux? Each main distribution? BSDs? Windows? Mac?

- does it include init scripts? Upstart config? Systemd?

- apparmor and selinux profiles?

- have you tested new versions of all your dependencies?

I'm sure not all points will apply to your project, but just be creative with those ideas :-)

Just do something useful. All of those points being some benefit to the project, even if tiny.

Depending on the software, testing in new environments and adding information about this, e.g. testing server software under current distributions. If you get user reports about this, there isn't even a need to do the tests yourself.

Maybe clearly say in the README: "This project is considered stable and therefore has less activity, but is not abandoned. I promise to remove this notice if this ever changes."

I actually just encountered this yesterday on a project. It had a disclaimer that said something like "This project isn't abandoned, we just maintain 0 bugs in the bug tracker. It's stable and ready for use, and if we get a bug report we'll fix it as soon as possible"

Reply on news.ycombinator.com