Difference between revisions of "GMOD Membership"

From GMOD
Jump to: navigation, search
m (Users)
m
 
(25 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{UnderConstruction|}}
 
 
 
This page describes how [[#Users|users]], [[#Developers|developers]], and [[#Software|software]] become a part of GMOD.
 
This page describes how [[#Users|users]], [[#Developers|developers]], and [[#Software|software]] become a part of GMOD.
  
 +
{{TocRight}}
 
== Users ==
 
== Users ==
  
To become a GMOD ''user'', just download and install one or more [[GMOD Components]].  That's it.  There is no mandatory registration process, and you don't have to meet any set of requirements.  ''GMOD is open to everyone.''
+
To become a GMOD ''user'', just download, install, and start using one or more [[GMOD Components]].  That's it.  There is no mandatory registration process, and you don't have to meet any set of requirements.  ''GMOD is open to everyone.''
  
 
You are ''encouraged'' to sign up to the (low-volume) [https://lists.sourceforge.net/lists/listinfo/gmod-announce GMOD Announce mailing list], and to the [[GMOD Mailing Lists|mailing list(s)]] for the components that you use.  You can also subscribe to the [[GMOD News|GMOD News RSS feed]].  These will help keep you up to date on both the project and the components you use.
 
You are ''encouraged'' to sign up to the (low-volume) [https://lists.sourceforge.net/lists/listinfo/gmod-announce GMOD Announce mailing list], and to the [[GMOD Mailing Lists|mailing list(s)]] for the components that you use.  You can also subscribe to the [[GMOD News|GMOD News RSS feed]].  These will help keep you up to date on both the project and the components you use.
Line 14: Line 13:
  
 
There are several ways to become a developer:
 
There are several ways to become a developer:
* You can write fixes or additions to [[GMOD Components]] that you already use, and then send the code (or a link to it) to the [[GMOD Mailing Lists|mailing list(s)] for that component.  If the update is widely usefule, the lead developer(s) for the component will then fold it in to the component and your fix will be included in the next release.
+
* You can write fixes or additions to [[GMOD Components]] that you already use, and then send the code (or a link to it) to the [[GMOD Mailing Lists|mailing list(s)]] for that component.  If the update is widely useful, the lead developer(s) for the component will then fold it in to the component and your fix will be included in the next release.
 
* You can become a developer with ''[[SVN|commit privileges]]'' and directly submit your updates to the [[SVN|source code repository]] for that component.  This is a good option if you contribute code frequently.  To get commit privileges you need to ask one of the developers already working on the component.
 
* You can become a developer with ''[[SVN|commit privileges]]'' and directly submit your updates to the [[SVN|source code repository]] for that component.  This is a good option if you contribute code frequently.  To get commit privileges you need to ask one of the developers already working on the component.
 
* Finally, you can become a developer by contributing a new component to GMOD.  See [[#Software|Software]] below for how to do that.
 
* Finally, you can become a developer by contributing a new component to GMOD.  See [[#Software|Software]] below for how to do that.
Line 21: Line 20:
  
 
== Software ==
 
== Software ==
 +
New [[GMOD Components|software components]] become a part of GMOD through a nomination and evaluation process.
  
New [[GMOD Components|software components]] become a part of GMOD through a number of ways. Sometimes people contact GMOD to suggest a program (often developed by them) for GMOD. ([[DIYA]], for example, joined this way.) Sometimes project staff identify a good candidate (for example, [[MAKER]]), and sometimes new components arise from within the community ([[Bio::Chado::Schema]]).
+
=== Nomination ===
 +
 
 +
Software can be nominated by its developers, by GMOD users, or by GMOD staff.  New components also arise from within the community. [[:Bio::Chado::Schema]], [[DIYA]], and [[MAKER]] are all recent examples of software becoming a part of GMOD.
 +
 
 +
Please contact the [mailto:help@gmod.org GMOD Help Desk] if you would like to nominate a new component. You can also nominate a component by posting to the [[GMOD Mailing Lists]] that are most relevant to the tool.
 +
 
 +
=== Evaluation ===
 +
 
 +
Nominated software is first evaluated by GMOD staff (currently the [[User:Scott|GMOD Project Coordinator]] and the [[GMOD Help Desk]]) to see if it meets basic [[#Requirements|requirements]] such as ''open source licensing'' and ''GMOD interoperability''.  We'll also confirm a ''good faith commitment of support'' on the part of the component's developers.  GMOD community members are then asked for feedback on the other requirements such as ''meeting a common need'' and ''useful over time''.  Community members are picked based on a known interest in the area the new tool addresses.  If appropriate, a whole [[GMOD Mailing Lists|mailing list]] will be asked to evaluate the software.
 +
 
 +
GMOD staff will then make a decision based on community input and responses from the developers.  The decision may be to include the software, to not include the software, or to include the software after additional development or documentation is done.
  
 
=== Requirements ===
 
=== Requirements ===
  
To become a part of the [[GMOD Components|GMOD suite]], a new piece has to meet several requirements:
+
To become a part of the [[GMOD Components|GMOD suite]], software has to meet several requirements:
 +
 
 +
; Meets a Common Need
 +
: First, the program must meet a common need in biological research.  A tool that is only useful with organisms that are two-dimensional (think butterfly wings), is probably not a good match for GMOD. Tools must be useful across a wide range of biology, and meet a widespread need.  Tools that support [[next generation sequencing]], [[:Category:Expression|gene expression]], [[:Category:Phenotypes|phenotypes]], or [[Comparative Genomics|comparative genomics]] are good examples of broadly applicable tools.
  
==== Meets a Common Need ====
+
; Useful Over Time
 +
: GMOD Components should be applicable and useful for at least several years.  For example, GMOD tends to avoid ''analysis'' tools because this area of bioinformatics is constantly changing.  However, the need to connect different analysis tools into reusable pipelines (see [[Ergatis]] and [[Galaxy]] for examples), is a common and longstanding need that will outlive any particular too.
  
First, the program must meet a common need in biological research.  For example, a tool that is only useful with organisms that are two-dimensional (think butterfly wings), then it is probably not a good match for GMOD.  A tools must be useful across a wide range of biology, and meet a widespread needTools that support next generation sequencing, gene expression, phenotypes, or comparative genomics are good examples of broadly applicable tools.
+
; Configurable and Extensible
 +
: GMOD tools should be usable in a wide variety of situationsDifferent user environments will require different configurations of the software.  GMOD components should make it easy for users to do this tailoring in configuration files - they should generally not have to change the source code itself to get what they want.  Another (complementary) way to achieve this is to have an extensible architecture where computer-savvy users can write plugins/extensions for tasks such as input/output using custom/local data sources and formats.
  
 +
; Open Source License for All Users
 +
: New GMOD software must have an [http://www.opensource.org/licenses Open Source Initiative (OSI) approved license], and that license must be free to all users.  The GMOD project is committed to [http://www.opensource.org/docs/osd open source principles].
  
==== Useful Over a Period of Time ====
+
; Interoperable With Other [[GMOD Components]]
 +
: New GMOD software must be interoperable with other [[GMOD Components]].  Usually this means that the software can export and/or import [[GFF]], or that it can connect to [[Chado]].
  
GMOD Components should be applicable and useful for at least several years.   
+
; Commitment of Support
 +
: The developers of the software must be willing to make a good faith commitment to support the new component for at least 2 years after joining GMODThis commitment includes setting up email lists, responding to user questions, writing and maintaining documentation, and adding new features and bug fixes to the code.
  
Avoid analsys b/c changes alotSupport tools for running analysis though.
+
: The current developers should also be open to new developers from the GMOD community contributing code and other support to the new componentThis ''open development'' model contributes to the long-term viability of the open source model.
  
 +
; Users and Support Mailing List(s)
 +
: Newly added software components must have user/support [[GMOD Mailing Lists|mailing list(s)]] and those lists must be publicly archived.
  
 +
; Public repository
 +
: The software component, including code, documentation and other supporting files need to be stored in a publicly accessible code repository.  This repository must also enable the addition of new developers over the life of the project.
  
 +
=== Non-GMOD Software ===
  
==== Has an Open Source License for All Users ====
+
Being officially part of GMOD has several advantages:
 +
* It tells users that software meets the [[#Requirements|requirements listed above]].
 +
* The software gets equal billing with other [[GMOD Components]] on the GMOD web site.
 +
* The software will be included in GMOD [[Training and Outreach]] activities, possibly including coverage at [[GMOD Schools]].
  
* OSI approved
+
However, a component does not need to be officially part of GMOD to have a presence in GMOD.  Any software that is useful to the GMOD community is of interest.  See [[:Category:External|External]] for a list of such software that currently has a page on the GMOD web site.  GMOD is particularly interested in tools (such as [[Artemis]]) that interoperate with GMOD components.  You don't even have to apply for GMOD membership to have an "external" page.
* Some grandfathered in
+
  
==== Interoperable With Other [[GMOD Components]] ====
+
=== Versions ===
  
Most often through [[GFF]] or [[Chado]].
+
These [[#Software|Software Membership Requirements]] change over time.
  
==== Good Faith Commitment of Support for at Least 2 Years ====
+
{| class="wikitable"
 +
! Version
 +
! Start
 +
! End
 +
! Comments
 +
|-
 +
! 2.0
 +
| December 2010
 +
| -
 +
| Added publicly archived mailing list, and publicly accessible source code archive requirements.  These revisions were [[September 2010 GMOD Meeting#GMOD Membership Requirements|discussed at the September 2010 GMOD Meeting]], and on the [[GMOD Mailing Lists]] in December 2010.  The proposed changes were favorably received at the meeting and on the mailing lists.  The Version 2.0 membership standard became official on 2010/12/21.
 +
|-
 +
! [http://gmod.org/w/index.php?title=GMOD_Membership&oldid=15465 1.0]
 +
| February 2010
 +
| December 2010
 +
| Formalized the nomination process and the previously informal membership requirements.
 +
|-
 +
! Informal
 +
| Conception
 +
| February 2010
 +
| The list of requirements evolved and grew over time, eventually resulting in Version 1.
 +
|}

Latest revision as of 22:59, 15 August 2013

This page describes how users, developers, and software become a part of GMOD.

Users

To become a GMOD user, just download, install, and start using one or more GMOD Components. That's it. There is no mandatory registration process, and you don't have to meet any set of requirements. GMOD is open to everyone.

You are encouraged to sign up to the (low-volume) GMOD Announce mailing list, and to the mailing list(s) for the components that you use. You can also subscribe to the GMOD News RSS feed. These will help keep you up to date on both the project and the components you use.

Developers

Developers are users who also contribute code back to the project. In the early days of GMOD every user was also a developer. This is no longer true, but every user can still become a developer.

There are several ways to become a developer:

  • You can write fixes or additions to GMOD Components that you already use, and then send the code (or a link to it) to the mailing list(s) for that component. If the update is widely useful, the lead developer(s) for the component will then fold it in to the component and your fix will be included in the next release.
  • You can become a developer with commit privileges and directly submit your updates to the source code repository for that component. This is a good option if you contribute code frequently. To get commit privileges you need to ask one of the developers already working on the component.
  • Finally, you can become a developer by contributing a new component to GMOD. See Software below for how to do that.

Developers are also encouraged to sign up for the GMOD Developer mailing list (and maybe GMOD Architecture as well).

Software

New software components become a part of GMOD through a nomination and evaluation process.

Nomination

Software can be nominated by its developers, by GMOD users, or by GMOD staff. New components also arise from within the community. Bio::Chado::Schema, DIYA, and MAKER are all recent examples of software becoming a part of GMOD.

Please contact the GMOD Help Desk if you would like to nominate a new component. You can also nominate a component by posting to the GMOD Mailing Lists that are most relevant to the tool.

Evaluation

Nominated software is first evaluated by GMOD staff (currently the GMOD Project Coordinator and the GMOD Help Desk) to see if it meets basic requirements such as open source licensing and GMOD interoperability. We'll also confirm a good faith commitment of support on the part of the component's developers. GMOD community members are then asked for feedback on the other requirements such as meeting a common need and useful over time. Community members are picked based on a known interest in the area the new tool addresses. If appropriate, a whole mailing list will be asked to evaluate the software.

GMOD staff will then make a decision based on community input and responses from the developers. The decision may be to include the software, to not include the software, or to include the software after additional development or documentation is done.

Requirements

To become a part of the GMOD suite, software has to meet several requirements:

Meets a Common Need
First, the program must meet a common need in biological research. A tool that is only useful with organisms that are two-dimensional (think butterfly wings), is probably not a good match for GMOD. Tools must be useful across a wide range of biology, and meet a widespread need. Tools that support next generation sequencing, gene expression, phenotypes, or comparative genomics are good examples of broadly applicable tools.
Useful Over Time
GMOD Components should be applicable and useful for at least several years. For example, GMOD tends to avoid analysis tools because this area of bioinformatics is constantly changing. However, the need to connect different analysis tools into reusable pipelines (see Ergatis and Galaxy for examples), is a common and longstanding need that will outlive any particular too.
Configurable and Extensible
GMOD tools should be usable in a wide variety of situations. Different user environments will require different configurations of the software. GMOD components should make it easy for users to do this tailoring in configuration files - they should generally not have to change the source code itself to get what they want. Another (complementary) way to achieve this is to have an extensible architecture where computer-savvy users can write plugins/extensions for tasks such as input/output using custom/local data sources and formats.
Open Source License for All Users
New GMOD software must have an Open Source Initiative (OSI) approved license, and that license must be free to all users. The GMOD project is committed to open source principles.
Interoperable With Other GMOD Components
New GMOD software must be interoperable with other GMOD Components. Usually this means that the software can export and/or import GFF, or that it can connect to Chado.
Commitment of Support
The developers of the software must be willing to make a good faith commitment to support the new component for at least 2 years after joining GMOD. This commitment includes setting up email lists, responding to user questions, writing and maintaining documentation, and adding new features and bug fixes to the code.
The current developers should also be open to new developers from the GMOD community contributing code and other support to the new component. This open development model contributes to the long-term viability of the open source model.
Users and Support Mailing List(s)
Newly added software components must have user/support mailing list(s) and those lists must be publicly archived.
Public repository
The software component, including code, documentation and other supporting files need to be stored in a publicly accessible code repository. This repository must also enable the addition of new developers over the life of the project.

Non-GMOD Software

Being officially part of GMOD has several advantages:

However, a component does not need to be officially part of GMOD to have a presence in GMOD. Any software that is useful to the GMOD community is of interest. See External for a list of such software that currently has a page on the GMOD web site. GMOD is particularly interested in tools (such as Artemis) that interoperate with GMOD components. You don't even have to apply for GMOD membership to have an "external" page.

Versions

These Software Membership Requirements change over time.

Version Start End Comments
2.0 December 2010 - Added publicly archived mailing list, and publicly accessible source code archive requirements. These revisions were discussed at the September 2010 GMOD Meeting, and on the GMOD Mailing Lists in December 2010. The proposed changes were favorably received at the meeting and on the mailing lists. The Version 2.0 membership standard became official on 2010/12/21.
1.0 February 2010 December 2010 Formalized the nomination process and the previously informal membership requirements.
Informal Conception February 2010 The list of requirements evolved and grew over time, eventually resulting in Version 1.