Issue 354: Management of issues and workflow
In the 39th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 32nd FRBR - CIDOC CRM Harmonization meeting, GB Issues about management adjustment proposal and workflow and attribution. In particular
(1) George presented a proposal about issues management and workflow. The crm-sig asked him to formulate a proposal should in lectical form to be answered by yes or no
(2) we discussed about the procedure of merge and split issue. It is decided, but not documented, to create another category of open issues. The decisions are:
- Any sig member can raise an issue and can ask for voting by email
- Any crm sig members can ask for veto
- We should describe this procedure on the site.
- Any decision taken in a meeting cannot be undone to the same meeting
The crm-sig asked GB to write the procedure
Heraklion, October 2017
Posted by George 18/10/2020
Dear all,
A very long time ago, a discussion was started about better documenting how to raise and manage issues in the CRM SIG.
The issue is still open and my name is on the homework.
The issue is documented here:
http://cidoc-crm.org/Issue/ID-354-management-of-issues-and-workflow
I have written a text attempting to answer to the issue:
https://docs.google.com/document/d/1qFCzMCuKWGBlsudP8xbDuAXaExd8bAFg4BZBBCWrPnY/edit?usp=sharing
I think essentially we want to update this:
http://www.cidoc-crm.org/issue-formulation
It is obviously a very large issue and I have had a first go at the text.
Your thoughts and insights and further additions/changes/questions would make this issue move forward I imagine. Thanks for your ideas and comments.
Posted by Richard Light on 19/10/2020
George,
As a (very) occasional contributor to CRM development, I'm confused about the Working Groups concept. The current issues list [1] has Working Group as a key concept, although only an insider would have the first idea what '1', '2', '3' and '4' might signify. In your document you appear to propose an incompatible change to the semantics of these magic workgroup numbers. Also, recording which workgroup the issue falls within isn't part of the information which you require for a new issue. Surely it's a key item of information to include?
I can see the sense in starting with issues which affect the core model as (1), then going to editorial changes to the specification as (2). Logically, though, I would then go to documentation which is further from the core model as (3), and finish up with community as (4).
Are we only allowed four numbers? If not, I would suggest adding 'implementation/interfaces' as (5). This would encompass issues relating to the implementation of the CRM in systems, and the interface between the CRM model and other ontologies/models/standards. I think it's an important area of work, and maybe it hasn't received the attention it deserves because it doesn't have a magic number.
Final point: the guidelines are silent on the process by which an issue number is assigned to an issue. Given that this is its primary key, I think it should be made clear how, and when, it comes into existence.
In the 48th CIDOC CRM and 41st FRBR CRM sig meeting (virtual), GB presented his HW (an outline of the text on how to raise an issue and the process whereby to resolve it). The sig assigned GB to incorporate comments received by sig members in the document, and then pass it to a group of reviewers (MD, CEO, TV). Then put it to an e-vote.
October 2020
The CIDOC CRM group of editors decided that Issue 310 be merged with this one as it forms part of the overall workflow proposed for initiating and resolving issues in the CRM.
HW: GB to incorporate the HW he had prepared for issue 310 (and the comments/feedback by the sig) in the HW he's got for 354
9 June 2021
Post by George Bruseker (15 June 2021)
How to formulate and resolve issues:
here is the updated text for that
Post by Martin Doerr (15 June 2021)
Dear George, all,
I think the procedure is a bit more varied. In the past, we had published by e-mail several details, which can be summarized as follows, in addition to this well-written text:
Anybody can raise an issue in the SIG or via e-mail.
* It is either an open question or a decidable proposal.
* An open question should be discussed by e-mail and in the SIG.
A decidable proposal, published by e-mail latest 5 days before a SIG meeting, can be decided in this SIG, if there is time, or the next SIG.
At any time, anybody can ask for e-vote for a decidable proposal, short-cutting the SIG discussion. If there is a veto vote, it must go to the SIG discussion.
At any time, a decidable proposal may be sent by e-mail or be formulated in the SIG to resolve an issue open for discussion. If it is formulated in the SIG, it cannot be decided in the same meeting, but only in the next meeting or via e-vote.
Rationale: the whole community must be informed about any proposal to be decided. It needs time to understand the consequences of a decidable proposal. In the SIG, we expect participants to be familiar with the proposal in order to save time, but also that major objections could be raised and published before the meeting so that they can adequately be addressed.
Comments?
Best,
Martin
Posted by George on 7/10/2021
Dear all,
In the last SIG I was charged with undertaking the incorporation of Martin's notes on the issues management procedure document.
The issue is documented here:
http://www.cidoc-crm.org/Issue/ID-354-management-of-issues-and-workflow
The document was not accepted pending inclusion of Martin's notes.
Post by Eleni (5 September 2022).
Dear all,
Please take a moment to revise this old HW by George, that has now been updated according to the suggestions made by the SIG.
Best,
Eleni