Closed rljacobson closed 5 years ago
I have put a small "How to contribute" section directly on the first page of the wiki. As you pointed out, the best way is to first talk to us on Gitter and I have pointed this out.
In addition, I started something I initially saw when working on JabRef: Tagging specific issue in the bug-tracker as "help-wanted" or "good first issue" if the problem is easy enough so that a new contributor can directly work on it.
So right now, I have created new issues that cover the things that should be a goal for 2019 and where OSS contributors could really help us.
Sounds reasonable.
The only recommendation that I have remaining that has any substance is based on the Reviewer's Checklist regarding community guidelines:
The Rubi README says:
But on the website there does not seem to be clear information about how someone should contribute code to Rubi. The website does have links to the Rubi GitHub Organization, the Rubi Gitter Community, and the GitHub issue tracker. So in the sense of reporting bugs, feature requests, and suggestions, I think it's good.
On the other hand, both the README and the wiki have information useful to someone wishing to contribute, even if that information is not fully fleshed out. The code base itself is easy to navigate and well documented.
Putting myself in the shoes of someone wishing to hack on the code and submit pull requests, I think I would have to contact the developers before I understood the path to do that. Perhaps the most simple and easy thing to do is to ask potential new contributors to contact you to learn how to contribute. When wiki is a bit farther along, you can direct them to the wiki.
To circle back to issue #6, presumably patches should pass the test suite before being submitted, but the test script isn't up yet.