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!
Martin
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
Vox:+30(2810)391625
Email: [email protected]
Web-site: http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
