[Crm-sig] NEW ISSUE: About CRM-SIG Decision processes

Martin Doerr martin at ics.forth.gr
Sat Mar 27 18:39:09 EET 2021

Dear All,

With this opportunity, and in response to George's message below, I'd 
like to repeat the decision taking rules CRM-SIG follows since early 
days. The early documents regulating our decisions may have been lost in 
the transition to the new Website. Therefore I raise a new issue to 
collect or reformulate these rules and publish them on the Website under 
"Activities" with a title such as "How we operate".

The rule is that an issue to be decided in a SIG meeting, it must have 
been published before the meeting in a "YES or NO" decidable form.

In the meeting, the justifications are presented and discussed.

If the justifications are not regarded as inconsistent, or insufficient 
(in particular new counter insight presented), the issue should be decided.

No decision is undone under the same issue. In order to question an 
issue, a new issue with sufficient further evidence should be raised.

This was introduced for good reasons (after a meeting in which the same 
issue was done and undone several times, and in the end the decision was 
just the arbitrary iteration when the session ended). It is a major 
element guaranteeing transparency and stability of the CRM.

The decision criteria are majority, *not 100% consensus*. The latter 
would leave us in the worst case unable to finish work. The explicit 
goal is the *widest possible consensus*, taking small majority votes as 
an indication of an unmature issue to be rejected.

In the past, we had, successfully and without opposition, applied 
*time-outs* for all discussions (5 to 15 min by clock), because the 
work-load is immense, and members are expected to read the submissions 
before the meeting.

The time-out has not been applied since several years, rather because 
the a-priori estimation of discussion time needed is itself very 
time-consuming. As a result, our decision processes have been slowed 
down, creating an *increasing backlog* of unresolved issues, and raising 
*severe concerns *in the community by which rules the actual issues for 
discussion are selected. On the other side, managing the harmonization 
and consistency of an *increasing number of extensions* requires more 
and *more efficient decision taking.**
Therefore I regard the characterization of an issue as "introduced at a 
final moment as a fait accompli" as inadequate, as long as it has 
followed the rules.

Specifically, and as a case study, Issue 511 was raised by Robert 
9/9/2020 and known, with the addition that: "there is an inconsistency 
right now (as you recognized long ago!) that should *not persist in 
version 7.0*".

During the following preparation phase of 7.1, the issue was not 
resolved because of lack of insight and homework about how this relates 
to CRMsci, and how to deal with not measured dimensions, such as results 
of weather forecast etc.

In March 2, I sent a decidable, consistent proposal by e-mail to 
CRM-SIG, well before the meeting, which was supported by Robert and not 
commented by anybody else.

As being a "last minute" correction of 7.1, this issue had priority in 
the meeting. Therefore it was scheduled for the first session on Monday. 
Instead the discussion time was consumed by issues of lower relevance, 
even though the session chair might have been aware of the relevance. 
Against my repeated questions, the issue landed in the end at the end of 
the agenda.

The issue was decided with a double vote, first if it was ready for 
being decided, after all pros and cons had been laid out, and secondly 
by the final decision, orderly following the protocols, as I understand.

Since the objections in the meeting "there is a community of use to take 
into account" concentrated on monotonicity in general, I would further 
like to point out, that version 7.1 contains 34 non-monotonic migration 
instructions, issue 511 being the 35th. All being defined in rules that 
can be solved algorithmically.

For those 34 decisions, exactly the same community argument holds, if I 
am not wrong. It was a major effort in a series of issues to base the 
decision why a concept belongs to CRMbase on a purely rational base, 
explicitly formulated in a guideline, starting with Issue 260: Review 
specializations of Appellation. This created *a precedent* that in 
*well-justified cases*, logical and intellectual consistency has 
priority over monotonicity, and what the community is used to. Inability 
to correct severe intellectual errors of the past would be fatal and 
question renew-ability overall.

Therefore the fact that Issue 511 is non-monotonic did not constitute 
new, issue specific evidence brought up in the meeting. The SIG decision 
judged it by majority as a well-justified case to break monotonicity. 
Details will be in the minutes.

Further, for respecting the community, non-monotonic changes after 
version 7.1 should be reduced to absolute minimum, but any future 
correction of a range of E1 CRM Entity is necessarily non-monotonic. The 
decided range of P39 can now be adjusted by monotonic corrections, if it 
would be necessary. *I hope we will never again *need non-monotonic 
changes after 7.1.

The discussion shows the problem of a single violation of the 
"bottom-up" modelling principle: Excessive generalizations hinder 
orderly evolution of a model. With issue 511 resolved, CRMbase does no 
more contain excessive over-generalizations, which I regard as a quality 
criterion, and it was a criterion to give it priority in the last 
meeting. It could have been avoided much earlier.

What are the lessons learned? In my opinion:

A) Overgeneralizing the range of properties is not a virtue to be more 
tolerant for future applications, but blocks proper evolution.

B) *Priorities of issues to be discussed* should be made even more 
clear. We ask the community for help. Teleconferencing has become mature 
enough. We need more engagement to participate in meeting preparation!

C) All participants to read carefully the issues and be prepared. All 
participants to understand discussion time as a rare resource and the 
rationale of the decision procedures.

D) *Session chairs* to change order of issues if necessary.

Please comment, what can be improved in our procedures!
Please all to make proposals how we can increase throughput, possibly by 
distribution, and yet maintain methodological and content consistency.

All the best and thank you all for your opinions to this issue!


On 3/25/2021 2:43 PM, George Bruseker via Crm-sig wrote:
> Dear all,
> I also think that the decision was taken too fast and introduced at a 
> final moment as a fait accompli. Regardless of the ontological purity 
> behind the decision, there is a community of use to take into account. 
> I indicated also a no vote to adopting this measure in the meeting for 
> this reason. I understood that the acceptance of going to an evote 
> would be to try to build the concensus, not indicate that it is a 
> realized decision and we can only change the details.
> It is no hill I want to die on, but I think given its practical 
> ramifications to the user community it should have either been given 
> more air time earlier in order to build concensus and consider 
> alternatives or have been left as an issue to resolve for another day.
> Best,
> George

  Dr. Martin Doerr
  Honorary Head of the
  Center for Cultural Informatics
  Information Systems Laboratory
  Institute of Computer Science
  Foundation for Research and Technology - Hellas (FORTH)
  N.Plastira 100, Vassilika Vouton,
  GR70013 Heraklion,Crete,Greece
  Email: martin at ics.forth.gr
  Web-site: http://www.ics.forth.gr/isl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210327/13b2fa06/attachment-0001.html>

More information about the Crm-sig mailing list