FHIR Chat · Ballot Status · terminology

Stream: terminology

Topic: Ballot Status

Grahame Grieve (Sep 30 2018 at 11:01):

I have gone through and triaged all the vocabulary ballot items from the normative ballot #2 for FHIR conformance items. This was rather more time consuming than we planned since a number of balloters did not follow the instructions to balloters, and balloted on things that were not changed between the ballots. (150 items or so). I have gone through an attempted to deal with as many of the identified issues anyway.

Grahame Grieve (Sep 30 2018 at 11:02):

We have little time to deal with these issues, so we will have to rely on effective and extensive block votes, and preparation before hand to maximise our use of committee time.

Grahame Grieve (Sep 30 2018 at 11:03):

currently, I have prepared 3 block votes, and scheduled 3 items for discussion by committee (which is only 2 issues). There are 3 items marked as 'follow up' waiting from comment from @Carmela Couderc (see above).

Rob Hausam (Sep 30 2018 at 11:09):

Yes. Vocab has the planning session in Q4 this afternoon. I'll need to slip out from the Connectathon for a bit to discuss and plan how to tackle this during the week.

Grahame Grieve (Sep 30 2018 at 11:14):

• block vote #1: 47 items: non substantive clarifications that we can make: all persausive or persuasive with mod
• block vote #2: 9 items that are not possible or not appropriate (some may be taken up in R5, and some are too late)
• block vote #3: 21 affirmative items where the balloter simply said "ok" in the spreadsheet. Dispose as "Considered - no action required"
• block vote #4 ("A" in gForge): 9 Items that are not related (out of scope of the ballot, and not actionable, or that need follow tasks with a different status)

Grahame Grieve (Sep 30 2018 at 11:18):

open issues for committee:

• GF#18564 and GF#18685 - relate to VSD-11. This issue is likely to force a reballot. (extremely painful for me, hard to describe how much, but there seems to be no choice)
• GF#18151 - it's definitely not related, and probably not persuasive, and definitely a problem at this time of ballot whatever, but we may be able to add some clarification around it

Grahame Grieve (Sep 30 2018 at 11:19):

all the items in block vote #2 and #4 come from @Carmela Couderc, @Jay Lyle @Rob Hausam - it is critical you review ASAP

Rob Hausam (Sep 30 2018 at 11:21):

Yes. Let's talk more on vsd-11. You can fill me in on the rest of your discussion last night.

Grahame Grieve (Sep 30 2018 at 13:18):

ok, so corridor dsicussion suggested a way forward for vsd-11

Grahame Grieve (Sep 30 2018 at 13:19):

here's a relevant value set:

<?xml version="1.0" encoding="UTF-8"?>

<ValueSet xmlns="http://hl7.org/fhir">
  <id value="action-relationship-type"/>
  <meta>
    <lastUpdated value="2018-09-30T07:09:17.602+10:00"/>
    <profile value="http://hl7.org/fhir/StructureDefinition/shareablevalueset"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2> ActionRelationshipType</h2>
      <div>
        <p> Defines the types of relationships between actions.</p>

      </div>
      <p> This value set includes codes from the following code systems:</p>
      <ul>
        <li> Include all codes defined in
          <a href="codesystem-action-relationship-type.html">
            <code> http://hl7.org/fhir/action-relationship-type</code>
          </a>
        </li>
      </ul>
    </div>
  </text>
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-wg">
    <valueCode value="cds"/>
  </extension>
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status">
    <valueString value="Trial Use"/>
  </extension>
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm">
    <valueInteger value="2"/>
  </extension>
  <url value="http://hl7.org/fhir/ValueSet/action-relationship-type"/>
  <identifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:2.16.840.1.113883.4.642.3.813"/>
  </identifier>
  <version value="3.6.0"/>
  <name value="ActionRelationshipType"/>
  <title value="ActionRelationshipType"/>
  <status value="draft"/>
  <experimental value="false"/>
  <date value="2018-09-30T07:09:17+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Defines the types of relationships between actions."/>
  <immutable value="true"/>
  <compose>
    <include>
      <system value="http://hl7.org/fhir/action-relationship-type"/>
    </include>
  </compose>
</ValueSet>

Grahame Grieve (Sep 30 2018 at 13:19):

this is a draft resource. So if you expand this, and ask not to include the definition in the expansion, you'll get this:

Grahame Grieve (Sep 30 2018 at 13:21):

      <ValueSet>
        <id value="action-relationship-type"/>
        <url value="http://hl7.org/fhir/ValueSet/action-relationship-type"/>
        <version value="3.6.0"/>
        <name value="ActionRelationshipType"/>
        <status value="draft"/>
        <experimental value="false"/>
        <expansion>
          <identifier value="urn:uuid:fdf2db77-45fc-4927-bae8-6dcc35161194"/>
          <timestamp value="2018-09-30T07:10:16+10:00"/>
          <total value="9"/>
          <parameter>
            <name value="excludeNested"/>
            <valueBoolean value="true"/>
          </parameter>
          <parameter>
            <name value="includeDesignations"/>
            <valueBoolean value="true"/>
          </parameter>
          <parameter>
            <name value="version"/>
            <valueUri value="http://hl7.org/fhir/action-relationship-type|3.6.0"/>
          </parameter>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="before-start"/>
            <display value="Before Start"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="before"/>
            <display value="Before"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="before-end"/>
            <display value="Before End"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="concurrent-with-start"/>
            <display value="Concurrent With Start"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="concurrent"/>
            <display value="Concurrent"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="concurrent-with-end"/>
            <display value="Concurrent With End"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="after-start"/>
            <display value="After Start"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="after"/>
            <display value="After"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="after-end"/>
            <display value="After End"/>
          </contains>
        </expansion>
      </ValueSet>

Grahame Grieve (Sep 30 2018 at 13:21):

this (from the ballot) fails to meet the invariant.

Grahame Grieve (Sep 30 2018 at 13:21):

but this does:

Grahame Grieve (Sep 30 2018 at 13:23):

  <ValueSet>
        <id value="action-relationship-type"/>
        <url value="http://hl7.org/fhir/ValueSet/action-relationship-type"/>
        <version value="3.6.0"/>
        <name value="ActionRelationshipType"/>
        <status value="draft"/>
        <experimental value="false"/>
    <compose>
     <extension url="http://hl7.org/fhir/StrutureDefinition/ValueSet-compose-removed">
      <valueBoolean value="true"/>
    <extension>
   </compose>
        <expansion>
          <identifier value="urn:uuid:fdf2db77-45fc-4927-bae8-6dcc35161194"/>
          <timestamp value="2018-09-30T07:10:16+10:00"/>
          <total value="9"/>
          <parameter>
            <name value="excludeNested"/>
            <valueBoolean value="true"/>
          </parameter>
          <parameter>
            <name value="includeDesignations"/>
            <valueBoolean value="true"/>
          </parameter>
          <parameter>
            <name value="version"/>
            <valueUri value="http://hl7.org/fhir/action-relationship-type|3.6.0"/>
          </parameter>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="before-start"/>
            <display value="Before Start"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="before"/>
            <display value="Before"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="before-end"/>
            <display value="Before End"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="concurrent-with-start"/>
            <display value="Concurrent With Start"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="concurrent"/>
            <display value="Concurrent"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="concurrent-with-end"/>
            <display value="Concurrent With End"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="after-start"/>
            <display value="After Start"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="after"/>
            <display value="After"/>
          </contains>
          <contains>
            <system value="http://hl7.org/fhir/action-relationship-type"/>
            <code value="after-end"/>
            <display value="After End"/>
          </contains>
        </expansion>
      </ValueSet>

Grahame Grieve (Sep 30 2018 at 13:23):

where the key is this:

    <compose>
     <extension url="http://hl7.org/fhir/StrutureDefinition/ValueSet-compose-removed">
      <valueBoolean value="true"/>
    <extension>
   </compose>

Grahame Grieve (Sep 30 2018 at 13:24):

this extension indicates the the compose has been removed (either at the request of the client, or because of system configuration) and any consumer of the value set will have to find the definition elsewhere if they wish to access it

Lloyd McKenzie (Sep 30 2018 at 13:25):

ick?

I can live with this for R4 if we're confident we can remove the rule in R5. How will we address the over-strict inter-version change rules?

Grahame Grieve (Sep 30 2018 at 13:26):

yes we can remove it in R5

Grahame Grieve (Sep 30 2018 at 13:28):

or change it to a best practice invariant

Robert McClure (Sep 30 2018 at 14:19):

Again, I think creating this hack that will mean that every terminology server will need to change it's code to stick a compose into every value set resource is a worse, more problematic result then simply removing the invariant. I think we need to investigate the ANSI rules to see if we can evoke the "no one implements this" clause and ask if everyone agrees to the change. Every TS implementer I have spoken to (5) already ignore this invariant. So we need to do the right thing, not play by crazy self-defeating rules, and find the rule that lets us do what we all agree is the correct solution.

Grahame Grieve (Sep 30 2018 at 14:21):

I ignore this rule. I will seek procedural clarification of this. But I suspect Austin will say no

Grahame Grieve (Sep 30 2018 at 14:23):

Be clear about this: we can make changes that break backwards compatibility if no one is affected. But we cannot make substantive changes to the ballot without reballoting on these grounds; it's a different thing

Grahame Grieve (Sep 30 2018 at 14:23):

what would be the best solution?

Rob Hausam (Sep 30 2018 at 14:24):

right

Grahame Grieve (Sep 30 2018 at 14:25):

to see if we can evoke the "no one implements this" clause and ask if everyone agrees to the change

ANSI says we can do this; it's called re-balloting. Which is the choice I recommended

Alexander Henket (Sep 30 2018 at 14:26):

I was just made aware of this issue, and can't believe I never thought of this, but status is sure broken.

ValueSet.status has double semantics. It means "status of the intention" on any ValueSet except those that carry the expansion. As soon as a ValueSet.expansion is present, now it means "status of the expansion".

Regardless of removing the invariant: it's hard to ignore that thing. The invariant just means I can never retire an expansion. Removing the invariant doesn't fix the double semantics.

The only way to properly fix this, imo, is to introduce a second status element. Preferably one status would always be about intention, and the other would always be about expansion

Robert McClure (Sep 30 2018 at 14:26):

SO how quickly can a re-ballot be done? And can it be targeted or will it open the gates to other changes too?

Grahame Grieve (Sep 30 2018 at 14:27):

well, Rob, we already had a limited ballot, and guess what? some (nameless) balloters ignored that fact that it was targetted....

Grahame Grieve (Sep 30 2018 at 14:27):

technically, I could argue that this is all out of scope and we'll just have to live with it

Grahame Grieve (Sep 30 2018 at 14:28):

I generally agree with Alexander - we could create an extension for expansion status, though I'm not sure how that actually works (good reason for it to be an extension)

Robert McClure (Sep 30 2018 at 14:29):

My problem with trying to accurately determine what the expansion status is will be hard. I'd rather not attempt to do that now

Alexander Henket (Sep 30 2018 at 14:30):

I'm sure a server that expands knows what the best applicable status for it is?

Robert McClure (Sep 30 2018 at 14:30):

And leaving the invariant still forces improper semantics on the element, especially when you also say there is an expansion status someplace else

Grahame Grieve (Sep 30 2018 at 14:31):

that was why I reluctantly recommended reballoting

Alexander Henket (Sep 30 2018 at 14:32):

Adding an extension for expansion status, should be accompanied by making sure the ValueSet.status is solely for intention status? And the invariant should still go too because that's what's forcing you to put expansion semantics onto ValueSet.status

Robert McClure (Sep 30 2018 at 14:32):

I'm starting to think that given the alternatives you say ANSI provides, we just choose to ignore and fix later. Tell folks that in an expansion-only vs, ignore the status.

Grahame Grieve (Sep 30 2018 at 14:34):

as much as I dislike reballoting, that's a worse idea

Robert McClure (Sep 30 2018 at 14:36):

it's worse to ignore that the status is always active?

Grahame Grieve (Sep 30 2018 at 14:36):

yes. It's worse to say that you should ignore the invariant that we publish, with the consequence that you have to ignore validating altogether

Grahame Grieve (Sep 30 2018 at 14:37):

since all our validators will enforce the invariant as stated

Rob Hausam (Sep 30 2018 at 14:39):

I doubt that’s what Rob meant by “ignore the status” in an expansion-only vs - basically, if it’s always active in that case you don’t have to do anything with it

Robert McClure (Sep 30 2018 at 14:43):

yes, I meant that we can let folks know that in an expansion only value set (vs) the status = active does not accurately reflect the status of the antecedent definitional value set status.

Rob Hausam (Sep 30 2018 at 14:48):

since the resource can contain both compose and expansion, we never clarified how a single 'status' field would apply and could be interpreted for all of the possible combinations - which gets to Alexander's points

Grahame Grieve (Sep 30 2018 at 14:50):

well, ok, I can go with that but it's orthogonal to the question of the invariant?

Rob Hausam (Sep 30 2018 at 14:52):

it's orthogonal, except that the invariant was an attempt (whether complete or correct or not) to address exactly this issue

Grahame Grieve (Sep 30 2018 at 14:53):

ok understand.

Grahame Grieve (Sep 30 2018 at 15:23):

@Robert McClure

" I think we need to investigate the ANSI rules to see if we can evoke the "no one implements this" clause and ask if everyone agrees to the change. Every TS implementer I have spoken to (5) already ignore this invariant."

This might have legs... I will let you know

Russ Hamm (Sep 30 2018 at 15:56):

Hehe, reminds me of Canada's "Notwithstanding Clause". :-)

Carol Macumber (Sep 30 2018 at 15:58):

We don't ignore VSD-11. Painfully we have already implemented it. Not to say that we will vote against removing it, because i agree it is flawed for all the reason we discussed this morning in-person. End users (who author, maintain and publish value sets) that I've queried are not happy with the proposed work arounds to extend status and/or compose. So my vote is to address the issue directly through removal/update of the invariant (and perhaps the status element) now instead of asking implementers to accept the klugey band-aid, knowing we have to fix it later.

Lloyd McKenzie (Sep 30 2018 at 16:01):

The tricky bit here is that while ANSI might allow it, our formally documented rules don't - and our formally documented rules include a process for changing those rules. It's hard to imagine meeting those requirements in less than a month and even that might be pushing it. We can't execute a process that's outside our own documented rules.

Grahame Grieve (Sep 30 2018 at 16:50):

on further review, no legs. We play the processes as described.

Alexander Henket (Sep 30 2018 at 17:27):

I've checked the ART-DECOR implementation: I copy the intention status onto the expansion. For our Nictiz projects, it just so happens that all exported value sets were 'active'. Coincidence, not planning. So far I've not heard from Germany, Austria or other places I know that export to FHIR, that they ran into issues on non-active expansions. I think it is safe to say though that the real world impact of non-compliance to vsd-11 isn't very high

Yunwei Wang (Sep 30 2018 at 17:58):

Late for this discussion. But our server ignores vsd-11.

Alexander Henket (Oct 01 2018 at 09:19):

@Grahame Grieve what does your last comment mean?

I interpret it as:
- add extension for expansionStatus
- leave vsd 11 for R4 counting on people ignoring it or circumventing it by adding compose
- write blogpost on the situation and fix it in R5

Rob Hausam (Oct 01 2018 at 09:32):

It would be good to have a clear restatement of what the intent is now to deal with this. I'm not sure that vsd-11 is quite as "broken" as has been suggested, but I agree that it is an ugly way to attempt (even if unsuccessful or with excessive side effects) to deal with an issue that does exist in the specification regarding the meaning and scope of the current 'status' element and the inability to separately and unambiguously represent the status of an expansion. Removing vsd-11 alone will not fix the entire underlying issue. So I would like to see again a complete description of what we will propose to do.

Alexander Henket (Oct 01 2018 at 09:48):

vsd-11 imposes double semantics on an element which is never good. vsd-11 also means you cannot retire an expansion. I agree that removal of vsd-11 could restore semantics for ValueSet intention only but it leaves leaves expansionStatus unaccounted for, for that you could add an extension. Stating expansionStatus might not be relevant in all use cases. Probably the resource-effectivePeriod is more useful

Rob Hausam (Oct 01 2018 at 09:56):

I agree with that, except that ValueSet.status is at the root level of the resource and applies (somehow) simultaneously to both 'compose' and 'expansion'. There is nothing stated that limits its scope to only the definition ('compose'). In the definition for 'status' it states that it "Enables tracking the life-cycle of the content" (emphasis mine) - both 'compose' and 'expansion' are part of the content. So, I don't think that removing vsd-11 and adding an extension for the expansion status will sufficiently fix the problem.

Alexander Henket (Oct 01 2018 at 10:01):

Right. you probably also need an update in the definition of ValueSet.status to be totally clear.

Rob Hausam (Oct 01 2018 at 10:05):

Agree. We need to give this further thought to make sure that we achieve the behavior that we actually desire for this. It's not entirely clear to me if we can do all of that even with a re-ballot - but I'm happy to hear more about how we think that will work.

Alexander Henket (Oct 01 2018 at 10:25):

If the goal of status is to track lifecycle, then it seems unreasonable to fix that lifecycle to 1 value 'active'. That's not tracking: that's mandating. So my proposal for if and when we fix this:

• ValueSet.status is reserved for tracking the status of the compose only
• ValueSet.expansionStatus (extension is fine too) is reserved for tracking the status of the expansion only
• vsd-11 has to go

Is this whole thing similar in nature to StructureDefinition.differential versus StructureDefinition.snapshot? I.e. we normally never produce snapshots in our profile and leave the expansion into snapshots to the server that you get the profile from. So now: what does the StructureDefinition.status mean? Does it span snapshot too although I never supplied that?

Grahame Grieve (Oct 01 2018 at 10:54):

vsd-11 is outright broken in that routine behaviors that are correct break the invariant. Removing it will fix that issue.

Grahame Grieve (Oct 01 2018 at 10:55):

I agree that removing it won't fix the issues around the status, but they can be deferred to R5, I think.

Grahame Grieve (Oct 01 2018 at 10:56):

still, pursuing them... when does an expansion have a status of it's own? In our best practice usage, the expansion has no status... you generate it, use it, and then dispose of it, or store it for audit purposes. It has no status, it just is

Grahame Grieve (Oct 01 2018 at 10:57):

you get to having a status if you're going to keep them around, share them, and re-use them, About which, we already say:

Grahame Grieve (Oct 01 2018 at 10:58):

http://build.fhir.org/valueset.html#storage

However, any system that stores an expansion must be concerned with how to determine whether the expansion is still current, and this requires deep knowledge of how the expansion was created

Grahame Grieve (Oct 01 2018 at 10:59):

I would favor adding an extension for expansion status, and adding a paragraph to this section that explains the issue, and mentions the expansion status extension, and the resource-effectiveDate extension

Alexander Henket (Oct 01 2018 at 11:34):

I'm not convinced either of a broad use case for expansionStatus, other than active by default, potentially retired at some point, but retained for historical purposes.

Lloyd McKenzie (Oct 03 2018 at 21:03):

There are a number of "out-of-scope" issues that not marked as "Persuasive" or "Not Related". Are we absolutely confident the voters will withdraw? Because if not, the motions should have been "Not Related" with any changes handled via non-ballot trackers

Grahame Grieve (Oct 04 2018 at 10:42):

which ones?

Rob Hausam (Oct 04 2018 at 10:44):

Let's look at which ones. If we really need to correct something, we probably could today. I'm going to work on getting GF caught up this morning.

Grahame Grieve (Oct 04 2018 at 13:07):

@Lloyd McKenzie

Lloyd McKenzie (Oct 04 2018 at 15:18):

Here's the list that have resolutions other than Not Related or Persuasive.

Lloyd McKenzie (Oct 04 2018 at 15:18):

terminology-issues.xlsx

Lloyd McKenzie (Oct 04 2018 at 15:18):

There's a lot of them...

Grahame Grieve (Oct 04 2018 at 15:56):

@Carol Macumber @Rob Hausam @Robert McClure @Ted Klein I hate to do this, but I just discovered an urgent new task for the normative content: GF#19307:

Found while surveying use of trial use extensions in normative content: "These code systems are not usually presented in a hierarchical fashion in a CodeSystem if they are represented in a CodeSystem at all. If they are, then the subsumes extension must be used."

Beyond the typo (missing "."), the comment is wrong procedurally and factually: cannot use "must" (should be SHALL) and cannot SHALL use a trail-use extension from normative content. Further, this is wrong: it's a holdover from before properties were defined. Implementers SHALL use a property to indicate additional parents not in the heirarachy.

We need to change this to "Implementers SHALL use a property to indicate additional parents not in the heirarachy." and reballot this as a substantive change

Ted Klein (Oct 04 2018 at 16:18):

Urk. Yes, this was wised, and not update when the change to do multiple subsumption with properties. As ugly as it is, we will have to reboot this and it is substantive. It is one of the things that needs fixing in the UTG import and resources and editor as well. Sigh.

Ted Klein (Oct 04 2018 at 16:19):

sorry for all the typos in the above...

Grahame Grieve (Oct 04 2018 at 17:04):

Please approve this task during Q4

Carol Macumber (Oct 04 2018 at 18:17):

ahead of the curve, we're wrangling it in Q3

Grahame Grieve (Oct 04 2018 at 18:25):

should I come join?

Carol Macumber (Oct 04 2018 at 18:40):

if you're free. we're slowing coming around the rose bush. Constellation D

Grahame Grieve (Oct 04 2018 at 18:45):

down in a sec

Carol Macumber (Oct 04 2018 at 19:00):

Vocab has moved and accepted the following resolution, with room for editorial cleanup:
1) From this section: http://hl7.org/fhir/2018Sep/codesystem.html#hierarchy
a) Remove "If they are, then the subsumes extension must be used." from
b) Remove "These code systems are not usually presented in a hierarchical fashion in a CodeSystem if they are represented
in a CodeSystem at all. "
2) Add a " If a code system has concepts that are subsumed by more than one concept, the code system SHOULD not be represented using the hierarchy structure in the resources. Irrespective of the use of structure or properties, it does not impact meaning"

Grahame Grieve (Oct 04 2018 at 19:04):

Thanks - appreciate it greatly

Rob Hausam (Oct 05 2018 at 16:33):

Looking at GF#19307 to update it in GForge, it appears to me that the most critical piece of the request in the tracker "Implementers SHALL use a property to indicate additional parents not in the hierarchy" was not included in the voted resolution (that Carol posted above). Tell me if I'm missing something. Also, the vote details (mover/seconder and counts) apparently weren't recorded. The minutes say "See gforge for details", but the tracker wasn't updated during the quarter. It's seeming to me for both reasons that we're probably going to need to vote on this again on the tracker call on Monday. Anyone else have other information or alternative suggestions?

Last updated: Apr 12 2022 at 19:14 UTC