Good issues for new contributors

[agitter]

Now that the Manubot manuscript is live at PLOS Computational Biology, I'm optimistic we'll see some traffic to this repository. Should we find a few issues here or at https://github.com/manubot/manubot that would be good for new contributors and label them with good first issue?

We may be able to find some tasks for Python programmers and some that are more general.

[rhagenson]

@agitter When you start labeling issues for new contributors feel free to tag me in any with greater priority than "eventually". Otherwise I will keep my eye out for instances where I can offer my help. In this same vein of conversation, do you have contributing guidelines for new contributors to follow?

[dhimmel]

@rhagenson what are your areas of expertise? Or areas where you'd like to contribute as a way of learning? Depending on your interests, we can suggest good issues for you to tackle. Do you have experience with Python, HTML metadata / web standards, continuous integration, Pandoc, LaTeX, Citation Styles Language? Plenty of opportunities in these different areas.

[rhagenson]

@dhimmel I am a Bioinformatician (for nearly a decade) and from your list I have experience with: Python, CI, Pandoc, and LaTeX. Not nearly as experienced in HTML metadata / web standards as I wish I was, but for the other areas of Manubot I feel comfortable tackling issues. (CSL I am aware of, but never done anything with.)

Bit more, perhaps irrelevant, background: I mainly program in Go, Python, and R as those are the easiest to work with biologists in. I keep a non-technical user in mind for all that I do so whenever/wherever I can I try to simplify the interface between tool and user -- generally by setting a default rather than needing more input from the user. I also am an HPC system admin and dabble in tools like Singularity (https://sylabs.io/) because of that.

[agitter]

Thanks for offering to help @rhagenson. I'm sure we'll find some issues to recommend that are interesting and relevant to your expertise. The Manubot issues could also be pertinent given your Python experience.

@dhimmel should we think about making a public roadmap to help us prioritize issues and features?

[rhagenson]

@dhimmel and @agitter would you want me to hold off on work until a public roadmap is in place, or am I free to review issues and find someplace I can help? With only the two of you I am sure you both have more pressing matters than triaging issues searching for where to put me to work. Perhaps such an issue triage is the first task I can set out on -- categorize issues into the aforementioned areas of Python, CSL, LaTeX, and so on to more easily track how many open issues there are in each area (in addition to the standard bug, duplicate, enhancement, etc labels).

[agitter]

@rhagenson you don't need to hold off work. Rather, your comment pointed out that we don't have a process place for helping grow the contributor community and guide new contributors. That's something for us to address.

One recurring request has been in regards to customization (e.g. #189). Stub pull request #261 gives a path to make local builds more easily customizable. Other steps toward easier customization would be valuable too.

[slochower]

Great points @agitter, I agree.

[agitter]

#88 could be another good short term issue. @slochower already has a proof of concept of Manubot continuous deployment running in GitLab. See my latest notes there.

[dhimmel]

Another option if you're interested in CI would be to try to migrate our Travis and AppVeyor CI workflows to GitHub Actions, as briefly discussed here. If GitHub Actions supports our CI needs and has an elegant interface with easier setup, then I think we'd likely switch to it. Exploring GitLab is important since it's source code is more open, but even if we get GitLab working we're faced with the tough decision to switch entirely or support both GitHub and GitLab. Although perhaps forcing us to consider supporting multiple services now is good.

Another possibility for contribution would be working on some of the manubot package citation infrastructure. manubot/manubot#129 is only partially complete. There is lot's of opportunity to standardize Manubot's citation terminology with other projects. Also creating a citation-by-id filter for pandoc would be HUGE! This has been started in manubot/manubot#99, but due to conflicts this PR should probably be remade ground-up. Makes sense to finish manubot/manubot#129 first.

[rhagenson]

@dhimmel and @agitter I did not mean to go radio silent on you both the past two weeks. I am trying to get a JOSS publication through review and have been exclusively working on that with the little time I had already. I hope no offense is taken on this front.

I will try some time this week to select a recommended issue to work on between rootstock and manubot and get started, but it might be slow progress on my part here while I continue/finalize work on the aforementioned publication. I would rather be transparent about where my time is going than leave you all hanging on a lack of work on my part without explanation. =)

[dhimmel]

I am trying to get a JOSS publication through review

Cool! Integrating Manubot with JOSS is something we've been interested in for a while. One question is whether JOSS could accept submissions of Manubot manuscripts or even use Manubot as the manuscript processing software. So your experience with JOSS could put you in a good position to help with these efforts.

I'm currently finishing manubot/manubot#129.

[rhagenson]

@dhimmel JOSS already has their own bot called Whedon that covers editorial tasks such as assigning reviewers, accepting manuscripts, and generating the rendered PDF. I see no reason why a transition to using Manubot for rendering is not possible. We can certainly approach this at a later time.

[rhagenson]

@dhimmel Given my lack of existing knowledge with both GitHub Actions and GitLab, I think more immediate work on my part should be on the customization front (e.g., #189 and #261). I am continuing the conversation over on #189 to reduce the number of cross-issue references.