search

dib-lab / khmer

In-memory nucleotide sequence k-mer counting, filtering, graph traversal and more
http://khmer.readthedocs.io/
Other
756 stars 295 forks source link

Define path to contributions for people looking for more involvement #858

Open ctb opened 9 years ago

ctb commented 9 years ago

A few people have talked to me about how to follow up on their first commit to khmer; we should put some more explicit suggestions in, and maybe provide a tag for these tasks so that the project maintainers will avoid doing them ;).

My suggestion after watching this week's sprint is that we should strongly suggest that people add to our tests. Perhaps we can encourage them to do so by outlining some tasks? _khmermodule.cc seems ripe: http://ci.ged.msu.edu/job/khmer-master/label=linux/216/cobertura/khmer/_khmermodule_cc/

Suggest task name "project-improvement" but other thoughts welcome - we should apply some positive marketing spin so avoid "polishing" etc.

drtamermansour commented 9 years ago

As a first time contributor, I would like to say that I really enjoyed the sprint. Titus, Micheal and luiz, Thank you. You did an amazing job to make sure that everyone get involved whatever his/her skills are. You are creating a wonderful platform for open source software development. I have some comments/suggests: 1) The developer documentation requires more work specially when it comes to the section of the testing. 2) I suggest adding couple short educational videos. One motivational video about the aim of the project and our vision to the importance of collaborative work for open software development. Another video to stretch the scope of involvement to include other projects e.g. screed, khmer protocols,.. . Third one to explain our implementation to the idea of software testing and so on. A couple minute video is a very easy way to spread the word. 3) The issues usually need much more clarifications. As any lab project, by time the lab members develop their own jargons/conventions. If we want to share this project with world, we need to make sure that every comment/issue is understood outside the lab environment. 4) I like the idea of "project-improvement": I suggest to move from the space of just fixing bugs to a new space by suggesting new extension projects e.g. plugins to allow khmer to pipe with other software, development of visualization tools, and so on.

P.S. I do not understand what did you mean by:

On Sat, Feb 28, 2015 at 7:44 AM, C. Titus Brown notifications@github.com wrote:

A few people have talked to me about how to follow up on their first commit to khmer; we should put some more explicit suggestions in, and maybe provide a tag for these tasks so that the project maintainers will avoid doing them ;).

My suggestion after watching this week's sprint is that we should strongly suggest that people add to our tests. Perhaps we can encourage them to do so by outlining some tasks? _khmermodule.cc seems ripe: http://ci.ged.msu.edu/job/khmer-master/label=linux/216/cobertura/khmer/_khmermodule_cc/

Suggest task name "project-improvement" but other thoughts welcome - we should apply some positive marketing spin so avoid "polishing" etc.

— Reply to this email directly or view it on GitHub https://github.com/ged-lab/khmer/issues/858.

ctb commented 9 years ago

On Sun, Mar 01, 2015 at 07:21:40AM -0800, Tamer Mansour wrote:

1) The developer documentation requires more work specially when it comes to the section of the testing.

Yes, although this may be better served by putting in links to things outside the project. I'll take a look at it the next time we do a sprint.

2) I suggest adding couple short educational videos. One motivational video about the aim of the project and our vision to the importance of collaborative work for open software development. Another video to stretch the scope of involvement to include other projects e.g. screed, khmer protocols,.. . Third one to explain our implementation to the idea of software testing and so on. A couple minute video is a very easy way to spread the word.

Interesting idea. I think you think we're more organized than we are (or at least than I am :)

3) The issues usually need much more clarifications. As any lab project, by time the lab members develop their own jargons/conventions. If we want to share this project with world, we need to make sure that every comment/issue is understood outside the lab environment.

50/50... every project develops its own jargon, and there's a limit to how much time we want to spend reaching out!

4) I like the idea of "project-improvement": I suggest to move from the space of just fixing bugs to a new space by suggesting new extension projects e.g. plugins to allow khmer to pipe with other software, development of visualization tools, and so on.

But I don't trust most people to develop stuff like that. Maybe it's just me?

I do not understand what did you mean by:

  • _khmermodule.cc seems ripe

There are lots of areas in _khmermodule.cc that could use more testing, and the tests aren't difficult.

  • positive marketing spin so avoid "polishing"

If you tell people they're merely "polishing" your software, they may underestimate the importance of such things. If, instead, you clarify how what they're doing is part of a larger scheme, more important, etc. then they may want to participate more.