Skip to content

Latest commit

 

History

History
61 lines (47 loc) · 5.18 KB

SOP.md

File metadata and controls

61 lines (47 loc) · 5.18 KB

WikiPathways SOP

This document attempts to define the scope, roles and processes involved in the WikiPathways project. It will serve as the basis for governing the WikiPathways development community to promote the project’s continuity and longevity. Ideally, it will facilitate the good practices that have led to our current success, while mitigating the effect of future challenges. The mission statement of the Organization will reflect our philosophy regarding open source, open access, no patents, no IP, no irritating advertisements, in addition to our non-profit status.

Scope

The principal focus of the WikiPathways Organization is improving the collection, curation and free distribution of biological pathways. In terms of the reach of our Organization’s governance and assignment of roles within our Organization, we anticipate having to make case-by-case decisions in the “grey boundaries” between WikiPathways and related projects (e.g., certain aspects of PathVisio and BridgeDb).

Roles

Board of Directors

  • 1 FTE or equivalent from the member’s group (dev, curation, admin, financial, etc, not including overhead)
  • founding members (i.e., co-authors on first paper)
  • advice long-term planning
  • annual meeting (can be virtual)

Community Coordinators

  • establishing new collaborations (research, curation, dev)
  • “face” of WP; Public relations
  • organizing workshops and jamborees
  • representing WP at conferences

Curation Coordinators

  • maintain list of curators; recruit new curators
  • monitor content
  • maintain guidelines, help, tutorials

Architects

  • develop roadmap, technical decisions
  • make day-to-day decisions on committing patches, granting svn access
  • receives dev/technical proposals
  • nominates, votes, decides on new architects
  • gatekeepers to code

Developers

  • a long-term, committed contributor planning to maintain svn access for an extended period
  • qualifications are covered in “Producing Open Source Software” by Karl Fogel. Basically, that they’ve demonstrated responsibility.

Contributors

  • sends in patches or has had temporary or short-term svn access

Curators

  • actively responds to their watchlist and new edits
  • this is an opt-in passive title, but we’d like to have a list

Admins

  • legal and financial concerns of the Organization
  • answers to the Board

Here is the list of currently held positions

Process

Roadmap

This is a document of future development. Any developer can propose ideas and changes to the roadmap. Architects prioritize proposals and decide. Architects don’t tell developers what to do, obviously, but the incorporation of the code is ultimately up to Architects. All grant proposals, project idea, and publications should be consistent with the roadmap, or else they should be proposed to be added to the roadmap, preferably PRIOR to commitments. This should be a publicly accessible, collaboratively edited document. This should be open, public. https://github.com/wikipathways/wikipathways.org/blob/master/ROADMAP.md

Project Portfolio

This is a working document of tasks that actually need to be done/maintained in order to keep project running. This will help track tasks as personnel change. This is currenlty an internal document.

Disputes

The goal of this policy is to encourage consensus building, as such we are avoiding rules based on simple majority and time periods. If at any time the policy facilitates political leveraging or loopholes that circumvent honest consensus building, then the policy should be reviewed and changed. This policy only applies to groups with project-level decision powers, i.e., Architects and Board members. While these groups are small, we can reasonable insist on unanimous decisions, with a default of status quo. As the groups grow in size, we need to allow for super-majority consensus, so that 1 does not block 20. This policy accommodates both situations by establishing the standard of 80%+ agreement. This mean at least 80% of the group must be in agreement: unanimous for groups of 4 or less; all but 1 for groups of 5-9; all but 2 for groups 10-14; etc. Termination of Board or Architect membership requires 80%+ agreement among the Board.

Legal Entity - Research Stage

We should investigate our options in terms of legal status as a non-profit foundation, or affiliation with such an organization. The benefits of such a status should include establishing WikiPathways as serious, long-term project and making new funding mechanisms possible. Role models we might look to include the Cytoscape Consortium, and Linux, Mozilla and Wikimedia. If defined as a US non-profit, for example, we should be clarify what restrictions or disadvantages there might be for international participation and funding, both collection and distribution. There is a significant cost to establishing a freestanding foundation. It may be more efficient to establish project within a non-profit that we trust, and shares our vision. There are even non-profit “incubators” that provide the legal umbrella, and allow for projects to grow independent over time.