wiki-archive/twiki/data/TAPIR/DecisionMakingProcess.txt,v

103 lines
6.2 KiB
Plaintext

head 1.5;
access;
symbols;
locks; strict;
comment @# @;
1.5
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.4;
1.4
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.3;
1.3
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.2;
1.2
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.1;
1.1
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next ;
desc
@Initial revision
@
1.5
log
@Revision 5
@
text
@Most part of the discussions related to TAPIR happen either in the official TapirMailingList or in the wiki. Participants include mainly people that are involved with the existing biodiversity networks as well as representatives from TDWG and GBIF. Anyone is free to join the discussions, suggesting changes or improvements. When something has to be decided, consensus is always attempted, which means that if anyone has serious disagreements with what's being decided, the process can take a longer time until an appropriate solution is found. To follow the process, you can join the mailing list and register in the wiki (RSS or automatic e-mail notifications can be used to track changes).
The XML Schema is stored in a public svn repository (see TapirSubversionRepository) where only a core group of people that is historically involved with TAPIR has write access. However, no changes should be made in the XML Schema that is stored in the repository without previous discussions and agreements. Anyone can claim write access to the repository after a certain level of involvement with the community. Also, any change in the repository triggers an automatic notification to the TapirMailingList.
The development of TAPIR follows a pattern similar to software releases. Whenever necessary, changes and improvements will constantly be incorporated to the XML Schema provided there's agreement. At a certain point, also subject to agreement, a "feature freeze" will take place, when only changes associated with corrections or other issues should be made. During that period the protocol should be evaluated by the community, and even prototype implementations can try to support the new version. When it has been recognized that the protocol is stable enough (if no serious functional issues are raised and no problems are detected in eventual prototypes) then a new official version is released.
@
1.4
log
@Revision 4
@
text
@d1 1
a1 1
Most part of the discussions related to TAPIR happen either in the official TapirMailingList or in the wiki. Participants include mainly people that are involved with the existing biodiversity networks and as well as representatives from TDWG and GBIF. Anyone is free to join the discussions, suggesting changes or improvements. When something has to be decided, consensus is always attempted, which means that if anyone has serious disagreements with what's being decided, the process can take longer time until a proper solution is found. To follow the process, you can join the mailing list and register in the wiki (RSS or automatic e-mail notifications can be used to track changes).
d3 1
a3 1
The XML Schema is stored in a public svn repository (see TapirSubversionRepository) where only a core group of people that is historically involved with TAPIR has write access. However, no changes should be made in the XML Schema that is stored in the repository without previous discussions and agreements. Anyone can claim write access to the repository after a certain level of involvement with the community.
d5 1
a5 1
The development of TAPIR follows a pattern similar to software releases. Whenever necessary, changes and improvements will constantly be incorporated to the XML Schema provided there's agreement. At a certain point, also subject to agreement, a "feature freeze" will take place, when only changes associated with corrections or other issues should be made. During that period the protocol should be evaluated by the community, and even prototype implementations can try to support the new version. When it has been recognized that the protocol is stable enough (if no serious functional issues are raised and no problems are detected in eventual prototypes), a new official version is released.
@
1.3
log
@Revision 3
@
text
@d3 1
a3 1
The XML Schema is stored in a public svn repository (see TapirSubversionRepository) where only a core group of people that is historically involved with TAPIR have write access. However, no changes should be made in the XML Schema that is stored in the repository without previous discussions and agreements. Anyone can claim write access to the repository after a certain level of involvement with the community.
@
1.2
log
@Revision 2
@
text
@d3 1
a3 1
The XML Schema is stored in a public svn repository ( http://ww2.biocase.org/svn/tapir/trunk/protocol/ ) where only a core group of people that is historically involved with TAPIR have write access. However, no changes should be made in the XML Schema that is stored in the repository without previous discussions and agreements. Anyone can claim write access to the repository after a certain level of involvement with the community.
@
1.1
log
@Initial revision
@
text
@d1 1
a1 1
Most part of the discussions related to TAPIR happen either in the official mailing list () or in the wiki. Participants include mainly people that are involved with the existing biodiversity networks and as well as representatives from TDWG and GBIF. Anyone is free to join the discussions, suggesting changes or improvements. When something has to be decided, consensus is always attempted, which means that if anyone has serious disagreements with what's being decided, the process can take longer time until a proper solution is found. To follow the process, you can join the mailing list and register in the wiki (RSS or automatic e-mail notifications can be used to track changes).
d3 1
a3 1
The XML Schema is stored in a public svn repository () where only a core group of people that is historically involved with TAPIR have write access. However, no changes should be made in the XML Schema that is stored in the repository without previous discussions and agreements. Anyone can claim write access to the repository after a certain level of involvement with the community.
@