R Hackathon 1/Discussion notes
- 1 R hackathon 1: Notes from the Thursday afternoon discussion
- 2 What should phylobase contain?
- 3 What sort of timeline should we aim for?
- 4 How can we maintain a community among R phylogenetics developers and users?
- 5 What is the right wiki to use?
- 6 How well is Mesquite integration working?
- 7 Feedback and announcements
- 8 Potential review papers
- 9 Training
- 10 What has/hasn't been useful during this meeting
- 11 Homework
R hackathon 1: Notes from the Thursday afternoon discussion
Moderator: Wayne Maddison
Notes: Todd Vision
What should phylobase contain?
- Phylo4, Phylo4D classes, for single & multitrees (point person: Bolker)
- I/O functions (point persons: Hiebl/O'Meara?)
- cross-package vignettes (point person: Vision)
- task view (point persons: O'Meara/Vision)
What sort of timeline should we aim for?
- Prerelease in January
How can we maintain a community among R phylogenetics developers and users?
- Set up a mailing list (see below)
- Hold a users workshop at the evolution meetings in Moscow, Idaho in 2009 (Harmon)
- Hole a users workshop at 2009 SICB meeting (Alfaro)
- Hold a parallel developers meeting at SICB/Evolution?
- Give a talk or poster at the 2008 Evolution meetings (O'Meara).
- Pursue a software maintenance grant? (anyone interested?).
- Package and maintain phylobase, and maintain individual packages (as desired) at Rforge (Lapp & Orme).
- Share benchmark files - currently in specialized folder within svn (Harmon).
- Share the new documentation on a community wiki (point person: ?).
What is the right wiki to use?
- We could either use the R wiki, or have a phylo wiki (similar to Bioconductor)? The consensus is for the latter.
- We will try to purchase the r-phylo.org domain (Lapp)
How well is Mesquite integration working?
- I didn't catch all the details of Wayne Maddison's talk here.
- Both R calling Mesquite and Mesquite calling R could be released win a month.
- R calling Mequite is easier, but it works on headless version of Mesquite (so no graphics).
- This will need lots of documentation, especially on the R side/
Feedback and announcements
- These items are the responsibility of the organizers.
- Set up an R comparative methods SIG mailing list (Lapp?)
- Send a survey out for feedback and to solicit other ideas.
- Write up a meeting report that collects the follow-up activities.
- Send an email notifying the comparative methods development community more generally of the availability of the report and allow people who could not be present at the hackathon to contribute before it is finalized.
- NESCent will also announce the v0.1 version of the package and wikisite on evoldir (and maybe R lists)
Potential review papers
- PLoS computational biology primer - typically a basic overview
- A paper about the S4 class for Evolutionary Bioinformatics (Kembel?)
- An Bioinformatics application note about the R/Mesquite interaction when that is more mature
- Trait evolution (lots of methods poorly characterized - possibly a review paper with some benchmarking).
Other opportunities to take advantage of NESCent resources
- See the NESCent website for details on these programs
- There might be a good working group proposal here (anyone interested?)
- NESCent is also happy to host multiple simultaneous short term visitors (at least 2 weeks) to allow subgroups to interact for longer periods.
- We are also happy to entertain whitepapers (see www.nescent.org for details) for informatics ideas that we might be able to fund that don't fit into the regular proposal categories.
- Put together communal slides and materials for teaching a workshop (Butler)
- Hold a summer grad workshop on macroevolution in R in lovely Idaho (Alfaro, Harmon)
- All participants should consider ideas for exciting Google Summer of Code projects, which, if NESCent participates next summer, will be solicited in March (All)
- Include an R comparative methods in module in the NESCent phyloinformatics summer course module (Vision)
What has/hasn't been useful during this meeting
- Bootcamps, breakouts - folks are generally happy with these.
- It might have been useful to have users testing code on more diverse operating systems.
- The voting to get people into groups that they wanted to work on was surprisingly successful.
- How were the preparations for participants? It seemed overwhelming based on the volume of email, but wasn't too bad in reality.
- What one simple bit of homework was most useful? Thinking about priorities ahead of time.
- Other comments? Talking more to end users at the beginning of the meeting would have helped with prioritization.
- Apart from continuing to complete tasks undertaken at the hackathon.
- ALL PARTICIPANTS: Everyone please look at the subgroup page of the wiki and update the block of text so that it provides a concise summary what you worked on, how far you got, where we can find the code/text produced, and what you or others need to do to follow up.