cjdns/doc/bugs/policy.md

Policy

cjd recently closed the issue tracker on his cjdns repo on the basis that it had the effect of encouraging people to submit errors, then wander off feeling like they had done their part in solving the problem (my words, not his (--ansuz)).

Several of us from within the community encouraged him to do so, justifying the action by considering that it had not been maintained in some time, and without having someone assume responsibility for its maintenance there was little reason to keep it around.

To make up for its absence, however, we decided to provide a fork of cjdns, with its own issue tracker which would be maintained by the community. There are quite a few of us who care enough about this project to invest our time in improving things, however, it should be understood that:

1. like cjd, we are contributing our own personal time to do so
2. many of us balance these volunteer commitments against full time jobs
3. our volunteers are generally intelligent, charming, motivated individuals who could otherwise spend their personal time cavorting with other similarly charming, intelligent, and motivated humans

With that in mind, the remarkably small group who have pushed to curate our documentation and maintain our cjdns fork could really use some help.

This document exists to explain how you can get involved, as well as what our terms are for continuing to offer our collective efforts

1. We are going to push harder to implement a stricter WTFM policy. If a solution to your problem has been documented, you will be directed to it. If it has not, it will be explained to you under the assumption that you will contribute documentation for the next person to encounter the problem.
2. If you say you will document something, but you don't, you might end up on a blacklist. Nobody is under any obligation to ignore you, and there will not be any repercussions for offering assistance. However, you probably want to avoid developing a bad reputation. Negative reenforcement tends to be ineffective, though, so you may want a method of encouraging people to contribute, and keeping track of those that have. VOILA! Contributing lands you on the contributers list.
3. Issues will be closed if nobody volunteers to investigate further. If three months go by, and nobody contributes more information, we may just assume that the problem has been solved. Similarly, if your issue is vague, or lacks a descriptive title, you will be asked to elaborate. If you do not, it will be closed.
4. Gitboria, a GitLab instance on Hyperboria, hosts the canonical repository for these documents. If at all possible, make pull requests or issues there, and not here on github.