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
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:
I have written a text attempting to answer to the issue:
I think essentially we want to update this:
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
As a (very) occasional contributor to CRM development, I'm confused about the Working Groups concept. The current issues list  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.