Originally posted by Michael.James.Clark
View Post
I would like to clarify one thing, however. It's not that the two types of documentation can't be discussed simultaneously, but that they shouldn't be discussed simultaneously. One targets developers, one targets users - and both need to be there. Since the thread started explicitly as a comment on the need to document better for future developers, I thought it might be more productive to keep them separate.
In terms of attracting users, the issues are (IMHO) more straightforward: a good manual, functionality and interface. However, All of that documentation needs to be complete for the development community to embrace a piece of software, in addition to the many other factors involved in getting new developers to buy in. (e.g. choice of language, modularity of code, design, development model, ease of contribution, etc.) I'd rather focus on the later set, as that's where the real meat of this conversation seems to be for me.
Originally posted by Michael.James.Clark
View Post
Second, I'd still separate the user/developer communities. While bioinformaticians do an ok job of appealing to users (far from good, but the basic elements are there), we do a terrible job of creating community projects, which is what I feel is really holding the field back.
Where the real gains are to be made in bioinformatics are in making better use of developer's time - If we had all 40 people who had written their own ChIP-Seq code working together instead of generating 40 different peak finders, I think epigenetics would really be accelerated as a field. That would have required a serious, coordinated central project or two in which the learning curve for new developers was as small as possible, aka: good code documentation, etc. Think of a single peak-finder core with the ability for different developers/labs to strap on new modules for it, much the same way R has modules... but now I'm starting to digress.
Anyhow, I agree with your other points on both sourceforge and rating systems. Though, I still think Nils' point makes sense: If we had a single collective bioinformatics repository, it would be much easier to build resources like the ones you've described around such a facility. Rating, project evaluations, and more open feedback mechanisms could all be integrated. I suspect by simply enriching for a bioinformatics population you'd find many of the mechanisms better used.
As long as we lack a unified project location (which is encouraged by the academic environment where each lab hosts their own projects), it would be a much greater challenge to integrate all of this. However, I can imagine a bioinformatics portal fulfilling that function.
Perhaps ECO would be interested in adding a new developer specific component to seqanswers?
(And yes, I just said portal - the 90's are going to hunt me down for using such an outdated meme.)
Leave a comment: