Hackathon Whitepaper Guidelines

From Phyloinformatics
Revision as of 18:28, 25 October 2010 by Hilmar (talk) (New page: <center><big>'''Guidelines for proposing a NESCent-sponsored hackathon'''</big></center> Successful hackathons address gaps in software or standards for which significant progress can be ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Guidelines for proposing a NESCent-sponsored hackathon

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 aggressively engage the community around a shared purpose and include the role of 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 the collaborative work is structured. Some of these are best considered already at the time of writing the initial proposal, such as those described by the following questions.

  • How will the organizers 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 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)? Graduate student participation is particularly welcome.
  • What is the plan for follow-up, particularly where continued collaboration, or community adoption, are required for success?

At the latest when funded, the organizing committee should also address the following questions in preparing for the actual event.

  • 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. A structure that allows for flexibility and course correction at the event is also desirable.
  • How will participants communicate before and during the event?
  • 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.

Participants

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

Cosponsorship

Please specify if other organizations or institutions may be able to contribute to the support of the event.

Schedule

Proposers may wish to suggest scheduling opportunities or constraints, although if accepted the final dates and other logistical details will be planned with the assistance of NESCent staff.

No Budget

A budget should not be included in the whitepaper. NESCent staff will estimate the budget and inform the organizers of any constraints, should the proposal be accepted.

Templates

For templates, see examples of past hackathons:

Evaluation

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.