[GenABEL-dev] joining the GenABEL project - what is the procedure?
Nicola Pirastu
nicola.pirastu at burlo.trieste.it
Mon May 27 14:42:17 CEST 2013
Dear all,
since I was of the people who asked to submit a package to the project I have given some thoughts on the matter, I'll try to summarize them quickly and see what you think about it.
1) Types of contributions.
I think that people could have whole packages or single functions which they have developed and would like to contribute to the project. I don't think we should create a new *ABEL every new contribution we have but probably we should see if some of the existing packages could host the new functions. For example let's say the some one writes new metanalysis functions probably they should go under MetABEL instead of going under a new name. I think that as the project grows this will happen more and more often, so probably we should think about it before hand.
2) The review process.
I think that Yurii's idea of having a review process is very good since I think that we should give some type of guarantee of what goes under the *ABEL name.
I guess basic requirements should be that the method behind the new package has some scientific base and that it is correctly implemented.
For future maintenance the code should also be readable and commentated. I think it should also provide correct warnings about wrong object types and so on so that if it crushes people at least know what is going wrong.
We could also add a list of "strongly suggested" requirements like CRAN compatibility for R based packages.
3) Integrability across packages.
I think that one of the important points that makes the difference between the different softwares is how much things are easy to get done. I think that one thing we should strongly suggest is that the new packages are compatible with the old ones and that they integrate with them. For example it makes no sense to me to use other file formats that gwaa.data class for genotyped data and phenotypes while DatABEL format should be used for imputed data. I think that this should not be mandatory since we want to encourage people in using our platform for their methods but it should be one of the strongly suggested requirements.
4) Maintainance.
I think we should require people to keep their packages up to date. I don't think that we want people to just drop off they package, put the ABEL brand on it and then disappear into nothing. Contributors should also try to drop by the forum every once in a while to check that there are no unanswered questions about their package. I think that support is one of the things that make a difference in software usage.
Sorry for being long, but I guess that if we do this right from the beginning it will avoid problems.
Best
Nicola
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.
More information about the genabel-devel
mailing list