

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

Perceived Problem: People glance at a repo and see that it hasn&#x27;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.<p>Example: I maintain a small repo which doesn&#x27;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&#x27;t want future people to skip over it because it has no update activity.<p>What does everyone do to show project activity?  Artificially update the README?<p>I really want a &quot;check in&quot; button I can display in the project README which basically says &quot;yup, the maintainer has actively been here!&quot;, assuring me that a seemingly unmaintained project is in a stable state and being watched over.
======
jcr
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.

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

------
viraptor
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.

------
detaro
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."

~~~
caw
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"

