Closed baskaufs closed 8 years ago
I agree that one maintainer is problematic. Also, a uniform maintenance scheme across vocabularies makes it easier for the supporters of the cyberinfrastructure that supports the needed resources, e.g. issue trackers, perhaps voting systems, backups, management of cloud support (e.g. github), ... .
As an example and minor correction: it's difficult to find out that Gabi Droege and I share the role of chair in various things AC, but it's largely by default, analogously to John W's role. Also, in Florence at TDWG 2013 Gabi presented a proposal to change the Image IG name to "Multimedia IG." My recollection is that this was approved by acclamation and reported at the final report session. But I am clueless of where to find such reports. IG chairs---whether for vocabulary or other kinds of resources---should have a single system for reporting the decisions of Task Groups or the IG itself.
No input on how to structure this, but ping me if I need to set up specific groups in GitHub. Those groups can be easily mentioned in discussions. For example: @tdwg/exec
Block on Issue #15
I see two options for where to find reports of the TG and IGs. There could/should be a page for the IG/TG on the tdwg.org website. Reports could be uploaded there. Or, an interest group/task group could choose to use a GitHub repository, in which case, the tdwg.org page will link to the GitHub location.
What is the nature of the document store in the tdwg.org rewrite to be finished real soon now? Also, will TG and IG convenors have authority to deposit documents there or will they have to ask someone to do it for them? If no, allow the IG/TG to deposit to github and let the tdwg.org managers do what they will, but at least let every page about a TG/IG reference github.com/tdwg/thatGroup.
A consensus seems to be emerging that the document store is will be GitHub. I don't think we've heard any cogent argument against that proposal, and it seems to have broad support. Git is arguably now the most popular code management technology, and we can use the collaborative infrastructure available on GitHub to great benefit.
The Interest/Task Group conveners (or delegates) will have the ability to manage specifications under development, of course, but I think the process of creating a formal release should reflect the authority of consensus behind it some way. That concept of "authority" might have passed its expiration date, but signaling demonstrated effectiveness has to be the value of any standards body.
This issue intersects process revision, as well as infrastructure, the documentation standard, and the role of TAG.
FYI the new TDWG website is online and conveners could get permissions to post documents there. In any case, they will need to approve the content for the TG/IG (see https://github.com/tdwg/infrastructure/issues/31 and https://github.com/tdwg/infrastructure/labels/IG%2FTG for all the IG/TG issues relating to the website)
However, if the IG/TG want to maintain their own GitHub project that is also acceptable. Documents could be posted there and then the main Typo3 TDWG site links to the GitHub.
Typo3 is a bit of a hassle but GitHub is also a bit much for TGs that have only a few documents and have a mailing list elsewhere.
Removed block on Issue #15, which is complete
In the 2016-05-04 TG hangout (https://github.com/tdwg/vocab/blob/master/meeting-notes/meeting-agenda-notes-2016-05-04.pdf), the consensus developed that vocabularies should be maintained by an Interest Group chartered specifically for the purpose of maintaining that standard. See the end of the notes linked above for details. This consensus has been articulated in section 2 of the draft Vocabulary Maintenance Specification: https://github.com/tdwg/vocab/blob/master/maintenance-specification.md
The Term Change Policy of the DwC Namespace Policy [1] specifies a significant role for the Technical Architecture Group (TAG). According to the Term Change Policy, the TAG receives requests for term changes and addition of terms, conducts public comment periods, and evaluates consensus. In practice, requests of term changes and additions are initiated by creating an issue on the Darwin Core Issue Tracker [2]. In practice, John Wieczorek, as convener of the Darwin Core Task Group, has usually initiated public comment and evaluated consensus.
According to the TDWG Standards Development Process [3], a Task Group is created within an Interest Group to develop a specific product within a specific time period. The TDWG Process does not specifically say that Task Groups must "go away" when their task is finished, but the job: "Maintain and update products that continue to be useful." is listed under the responsibilities of Interest Groups.
So the crux of this issue is: who should bear the primary role for the maintenance of a vocabulary standard? For example, in the case of Darwin Core, should the responsibility be borne by the TAG, a permanent Darwin Core Task Group, or DwC's parent Interest Group, the Observation and Specimen Records Interest Group?
The reality is that the existing vocabularies (Darwin Core and Audubon Core) have individuals serving as their "shepherds" (John Wieczorek in the case of Darwin Core and Bob Morris in the case of Audubon Core), and those shepherds tend to be the ones who make sure that things "happen" with the standards they are shepherding. This is a heavy responsibility for a single individual and there should probably be some shared responsibility in the event that the "shepherd" becomes unwilling or unable to continue in that role in the future. The TDWG Vocabulary Management Task Group (VoMaG) report [4] recommendation 5.10 recommends "A ratified TDWG vocabulary must publish a list of experts who are responsible for maintaining and evolving the vocabulary in response to community feedback." What do we call this group? How do we know who are members? How does one join or leave the group?
It would be desirable to define some workable administrative structure that reflects the reality of how we want and expect vocabularies to be maintained in TDWG and then enshrine that structure in the actual Vocabulary Maintenance Specification. If the TAG is to have a significant role, then its composition and mode of operation should be specified.
It would also be good to have the specification describe a mechanism for tracking proposals that reflect the reality (i.e. using an online issue tracker rather than contacting the TAG).
For reference, this Issue addresses Recommendation 2.13, 2.16, 2.18, and 5.10 of the VoMaG Report. [4]
[1] http://rs.tdwg.org/dwc/terms/namespace/index.htm#classesofchanges [2] formerly on Google Code, now at https://github.com/tdwg/dwc/issues [3] http://www.tdwg.org/about-tdwg/process/ [4] http://www.gbif.org/resource/80862 and clickable from this group's README page