Hackathon Whitepaper Guidelines

From Phyloinformatics
Revision as of 05:50, 29 September 2011 by OpenIDUser3 (talk) (No Budget)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Guidelines for proposing and planning a NESCent-sponsored hackathon

In order to be responsive to the needs of the evolutionary biology community, NESCent is soliciting short whitepapers on potential informatics initiatives to be undertaken by the center. This includes proposing a hackathon (see a list of past hackathons held at NESCent) or a similar one-time event with a cyberinfrastructure focus. The following proposal guidelines were distilled from past events.

Successful hackathons address gaps in software or standards for which significant progress can be made through short, intense, collaboration among a group of (typically 15-30) individuals. Hackathons have the most impact when they engage a diverse community around a shared purpose and serve as a training ground for open software development skills and culture.

Proposal content

We recommend that proposal whitepapers address several specific points, including the following.

Motivation and Background

Explain the goals of the event, why these are of broad importance, and why a hackathon is a suitable approach for achieving them. Hackathons are best suited for implementation targets towards well-defined problems, as opposed to open-ended research questions. Identify a coherent set of focus areas that allow for critical mass of developers. Include a description of the current infrastructure gaps that the hackathon would help to fill, and of existing software or standards that will be leveraged or extended by this event.

Execution plan

Key to the success of the event are the processes by which participants are selected, development targets are chosen, and collaborative work is promoted. Whether before or after the whitepaper is submitted, event organizers will ultimately need to consider the following:

  • How will they identify and enlist qualified participants? There is typically a mix of invited and self-nominated participants, with less than half in the former category, and there is a formal process for soliciting self-nominations and reviewing applications.
  • How many participants are needed to address the goals, and from what different backgrounds or projects?
  • How will organizers ensure a diversity of participants (including not only expertise, but also career stage, gender, and other factors)? We especially encourage the involvement of students.
  • What is the plan for follow-up, particularly where continued collaboration, or community adoption, are required for success?
  • How will the event be structured to achieve outcomes that address user needs? Often, end users are included as participants in order to guide development, contribute to documentation and perform testing.
  • How will training in relevant skills (such as use of open development tools and infrastructure) be incorporated into the event?
  • How will groups form and development targets be decided? Preparations ideally include advance team-building and knowledge sharing. Advancing consensus and planning for a particular development target may benefit from smaller conference calls limited to those interested in the respective target. A structure that allows for flexibility and course correction at the event is also desirable.
  • How will participants communicate before and during the event? Besides a mailing list, one or two conference calls encompassing all participants have been found helpful in kicking off communication and preparation. Also, you might consider emerging communication channels such as Twitter for combining all types of updates into a single channel.
  • How will outcomes be documented, and who will be responsible for documentation?
  • How and when will code or other products-in-development be shared among participants, and with the community?

Organizing committee

The organizing committee will typically draft the whitepaper collaboratively. The committee should have 3 to 5 members representing a breadth of expertise and showing commitment to inclusion of a diverse set of participants. The whitepaper should concisely describe how each of the organizers meets the following expectations:

  • A strong professional interest and expertise in the target area
  • A commitment to be involved in the planning, execution, and follow-up stages.
  • Experience with open development practices.

If the proposal is accepted for support, one or more NESCent informatics staff members will be assigned to join the organizing committee, in order to serve as a liaison with the center staff and to assist in organization of the event.


When known, provide a list of suggested participants that will provide critical mass, with a description of their relevant qualifications. International participants are encouraged, but domestic participants should be in the majority.


Indicate if other organizations can, or may be able to, contribute to the support of the event.


Suggest scheduling opportunities or constraints. If accepted, the event dates and other logistical details will be planned with the assistance of NESCent staff.

No Budget

No budget need be included in the whitepaper; NESCent staff will estimate the budget and inform the organizers of any constraints, should the proposal be accepted. If funding commitments from cosponsors have been secured, they should be included in the whitepaper.


For templates, see examples of past hackathons:


Similar to other whitepapers, hackathon proposals will be evaluated by the following factors:

  • The perceived need within the evolutionary biology community.
  • The anticipated impact on facilitating evolutionary synthesis.
  • The disciplinary diversity of the scientific communities that are affected.
  • The tractability of the proposed target problems by a collaborative development sprint.
  • The match of required resources with what the Center can provide.
  • The alignment with informatics initiatives or collaborations already undertaken by the Center.
  • The extent to which the success and timeliness of addressing the target problems would depend on the participation of the Center.

Proposals are typically reviewed by the Operations Committee within a month of submission. Allow at least four months between the approval of the proposal and the hackathon event.

Further Reading