Skip to content

Latest commit

 

History

History
41 lines (34 loc) · 5.53 KB

MOTIVATIONS.md

File metadata and controls

41 lines (34 loc) · 5.53 KB

Basic motivations for the creation of an OS organisation:

  • For the Hydra Specification to be approved we need adoption. Considering the connatural complexity of Semantic Web technologies, the only way to make Hydra to reach adoption in an ample enough scale is to provide formation about how to develop REST APIs using Hydra and create proper tools to facilitate this adoption;
  • Formation is by definition time-consuming as much as the subject is complex, for this reason we see a great opportunity in leveraging the resources donated by Google Summer of Code or coming from any other possible source of donations.

Advantages:

  • The Open Source landscape is by definition fragmented and many players present themselves to their possible user-base; that can be made of single users, companies or other OS organisations. It is important to be properly represented among these by planning our public exposure online and through events.
  • The Organisation can become a consistent representation of the developing efforts of the Community, so that achievements and objectives can be clearly represented to the public.
  • The Organisation can be the trend-setter for defining quality standards for official tools.

Disadvantage:

  • Book-keeping and bureaucracy
  • More responsibilities because of resource allocation
  • ...

As reference use this collection of guidelines

Objectives of the Statute: Community ruling

Major objectives have to be defined and possibly written into flow charts and eventually into a repository that allows to compute via a CLI the status of a member according to different variables. Examples are carried below through "i.e."s:

  • Create a governance mechanism that defines a "Deck" (like a "Board" or a "Assembly") where decisions are taken, and establish clear rules about who can be a candidate and enter the decision-making process. A contributor with decision-making privileges is a "legate" or "holds a legation" (same root as "legacy").
  • Define how voting takes place in Decks (i.e. 100% for a Deck as large as 3; for value larger than 3 that are a value (x) in the series of the Fibonacci subtract 0.1x. Until the precentage needed reaches the threshold of 55% and cannot be lower. Until a threshold of 50 legates, 100% of active (non-resigned) Founders can take a decision.)
  • Define the status of contributor (i.e. 18 months of continuous participation from the first meaningful patch merged to master, Decks decide what meaningful contribution is, from the starting principle that whatever justified the release of a patch or greater version bump is defined as meaningful for the life-cycle of the library. Again, the status is not automatic, has to be requested and voted by the Deck. "Continuous participation" involves contributions to any of the official reporitories AND continuous participations to conference-calls and meetings for the 18 months).
  • Define the time and ways how a developer can become a legate or holds a legation (i.e. being a contributor and been provided vouching, or approval, from at least 3, or 60% if the Deck is larger than 6, of the existing Deck. A new threshold has to be set by modification of this Status if number becomes larger than 15. Or, in alternative, having successfully participated at a GSOC edition as student. Being a legate is not automatic, the change of status has to be submitted and approved by Deck with a majority of at least 67%, and renewed every 2 years by the current Deck before expiration of legation).
  • Define the status of "legate": duration and renewal of members (i.e. legation last 2 years and can be renewed with the criteria needed for the legation status. Founders are legates for life, except if they decide to leave the Community; in this case they can resign to the Deck. Every two years the statuses are re-assesed. Numbers of legations can vary according to the rules established in the Statute. Expiration/amendation of statuses takes place at the end of two editions of GSOC starting from the first after the Statute is approved and commited to different Git platforms of choice).
  • Define a mechanism to change this Statute (i.e. In the case that the Deck is larger than 3, the Statute can be changed according to a proposal submitted by 50% of the Deck and voted by the 2/3. For this special voting sessions, Founders' vote shall be computed as 2. For smaller Deck, 100% of votes is required. The initial revision of the Statute itself has to be voted by the 100% of the Founders)
  • (i.e. The status of Founder is acquired because of being a "starting Founder" (founders that signed the first revision of this Statute) or because assigned by 100% of the active Founders to other contributors for exceptional contributions to the Community, "adding Founder").
  • (i.e. The activity of governance take place in the Forum at https://groups.google.com/d/forum/hydraecosystem)
  • (i.e. Accounting of reources takes place in a platform that allows transparent allocation (https://opencollective.com/hydra-ecosystem). Allocation of resources is a duty of the Deck that define a "Checker" (a treasurer) and a deputy. In the beginning and until changes the "starting Founders" are also all checkers)

The objective is to have these procedures all automated via a Web-app and the results stored in a DAG.

Official Point of Contacts

  • Deck: collaborative mailbox
  • Community Announcements and Opinions Forum: [email protected]
  • According to this paper the optimal scale of a large/popular OSS project is 30-50 active contributors