Make it easy for submitter to take back an already submitted proposal for edits

[ribose-jeffreylau]

Currently, it is not possible for the submitter to undo submit in order to edit it.

Adding "Return for clarification" does exactly this.

from discussion with @maccraymer

[maccraymer]

Do not use "clarification" as the name for this action. It will be confused with the action called clarification (where minor corrections are made to existing items). Just call this action "Return to submitter" as done in the current registry. That action brings up window where the reason for returning the proposal can entered. See the current registry for how these management functions are implemented. -Mike

[ronaldtse]

Some fix up here is necessary for the terminology of classifying changes as "Supersession" and "Clarification".

[maccraymer]

My point before was that the *label* "Return for clarification" could be confusing when there is also an action called "Clarification". For example, if returning a supersession proposal, someone may think that "Return for clarification" means we want them to re-submit the proposal as a clarification and not a supersession. We need the ability to return a proposal to the submitter for revisions but I suggested not to use "clarification" in the label for that function to avoid any possible confusion. Call it "Return to submitter" or "Return for revision". -Mike

[ronaldtse]

Agree that "return to submitter" is a reasonable.

However, if the intent is to "not possible for the submitter to undo submit in order to edit it", then shouldn't it be "retract proposal" for the submitter?

How about this?

• submitter wants to cancel submission (the actor is the submitteR): "Retract submitted proposal"
• register manager wants to send back submission without "rejecting" (the actor is the register manager): "Return proposal to submitter"

[strogonoff]

@ronaldtse

submitter wants to cancel submission (the actor is the submitteR): "Retract submitted proposal"

This is already implemented as the withdrawal transition. Reasons: (1) feature parity with Java backend, (2) 19135 compliance.

register manager wants to send back submission without "rejecting" (the actor is the register manager): "Return proposal to submitter"

This is already implemented as “return for clarification”. Reasons: (1) feature parity with Java backend. I don’t think this is necessarily in 19135 (not in the current draft), though it can be considered part of proposal process designed by register owner.

--

The intent behind this suggestion was to have a sort of non-final withdrawal transition.

Withdrawal is final in our implementation. However, the point was raised that it might not be against the standard, and could be useful, if there was an option not to withdraw forever but to “take back” proposal for edits.

• The proposal would transition to “draft” state and be removed from the list of proposals pending register manager or control body review.
• All transitions for “draft” will apply (the proposal can be resubmitted again to register manager).

Why I personally am cautious about this option:

• This means one more way to “yank” the proposal from under control body or register manager nose, and one more possible race condition.

  Currently, the ability to withdraw proposal at any time (which I think is required per current 19135 draft) means submitter can withdraw proposal even while control body is actively looking at it; moreover, it means submitter can choose to withdraw at the same moment as control body chooses to accept.

  Now, we can assume withdrawal would be very rare, because withdrawal is final and has the vibe of a nuclear option. You’d have to create and submit a new proposal, which is somewhat of a barrier.

  But with the feature being discussed in this thread there would be an option to submit the proposal without making up one’s mind due to a streamlined ability to yank the proposal, make changes and resubmit. Same issues as with the withdrawal transition; except this transition can be expected to be more heavily used, which could pose problems.

I personally find it reasonable that submitting a proposal means relinquishing control over its future to register manager and control body; with withdrawal as exceptional escape hatch.

[strogonoff]

• This issue belongs to RegistryKit repository (transferred back)
• Let’s not put button label in issue title, seeing as it’s far from settled, and try to succinctly describe the core idea of the proposed use scenario instead (rephrased)

[ronaldtse]

As @maccraymer raised, the usage of "return for clarification" phrase can be easily misinterpreted, because ISO 19127 (the standard for the ISO GR) utilizes the term "clarification" from ISO 19135, where it means "minor change in a register item".

Currently, the ability to withdraw proposal at any time (which I think is required per current 19135 draft) means submitter can withdraw proposal even while control body is actively looking at it; moreover, it means submitter can choose to withdraw at the same moment as control body chooses to accept.

I think it is fair for the submitter to retract a proposal since the submitter submitted it. I don't think there is a race condition since our process is an atomic one.

Now, we can assume withdrawal would be very rare, because withdrawal is final and has the vibe of a nuclear option. You’d have to create and submit a new proposal, which is somewhat of a barrier.

I think this stigma should be removed. Withdrawal isn't a nuclear option. It could be a "retry" as well. We can provide the ability to "clone" a proposal to make a new one.

I personally find it reasonable that submitting a proposal means relinquishing control over its future to register manager and control body; with withdrawal as exceptional escape hatch.

I agree. It would be much easier to "reject", then the submitter can "clone" the proposal, edit it and re-submit it.

[strogonoff]

As @maccraymer raised, the usage of "return for clarification" phrase can be easily misinterpreted, because ISO 19127 (the standard for the ISO GR) utilizes the term "clarification" from ISO 19135, where it means "minor change in a register item".

This issue, created based on latest Monday meeting, is about an idea for a new transition that did not exist in Java backend.

Perhaps we should file a separate issue if we want to rename a transition already implemented as in Java backend (note that it would mean that transition name would be different from the same transition in Java backend).

I think it is fair for the submitter to retract a proposal since the submitter submitted it. I don't think there is a race condition since our process is an atomic one.

It is a race condition in this sense: two people can press a button, but results are mutually exclusive. Only one person gets the desired effect.

I think this stigma should be removed.

I don’t think there’s a stigma, only respect for register manager’s/control body’s time. It’s nuclear because that would mean any review effort was for nothing.

I agree. It would be much easier to "reject", then the submitter can "clone" the proposal, edit it and re-submit it.

I personally like this idea. It would be similar to the upcoming “clone” functionality for register items, and it also allows the user to essentially take a proposal back for changes (withdraw -> clone -> edit -> propose again).

[ronaldtse]

It is a race condition in this sense: two people can press a button, but results are mutually exclusive. Only one person gets the desired effect.

This is actually what "Atomic" means -- the data will not be in a broken / in-between / inconsistent states. Only one person gets the desired effect and the other action fails. This is exactly what we want. A "race condition" is used to describe conditions where both users do not get what they want.

@maccraymer said:

Do not use "clarification" as the name for this action.

@strogonoff said:

This issue, created based on latest Monday meeting, is about an idea for a new transition that did not exist in Java backend.

There seems to be some conflict here? We don't need to discuss the Java implementation here and we are not going to make any changes to it.

If this issue is to implement a "new function" that allows a "submitter to take back" a proposal, I would instead suggest to make these steps easy:

• retracting a proposal
• starting a proposal based on an old proposal
• submitting a proposal

This is as easy as just "send back without rejecting", aka in GitHub PR terms "close the PR" instead of "merge", "reject" or "approve".

[strogonoff]

This is actually what "Atomic" means -- the data will not be in a broken / in-between / inconsistent states. Only one person gets the desired effect and the other action fails. This is exactly what we want. A "race condition" is used to describe conditions where both users do not get what they want.

From programming and data type perspective, you are correct, there is no race. It’s a race in broad sense from user interface design and experience perspective. It may be a poor choice of a term admittedly.

A good GUI would attempt to rule out such scenarios through, for example, locking. In our case one of the tradeoffs of DVCS is that locking is difficult unless we introduce a centralized server in the mix.

I would instead suggest to make these steps easy:

I’m OK with the idea of implementing a “clone proposal as a new draft” feature that could be used on withdrawn proposals instead of introducing a new “take back for changes” transition, though I wonder what Mike would think since the latter was his idea…

[ronaldtse]

A good GUI would attempt to rule out such scenarios through, for example, locking. In our case one of the tradeoffs of DVCS is that locking is difficult unless we introduce a centralized server in the mix.

I think these days people are quite tolerant of these issues (i.e. "action failures") as long as they are given the option to retry (or refresh). People just quit an app and restart it.

To me the good GUI here would be allowing people not to lose their work.

Here the only two possibilities are:

1. Control body approved and submitter cannot retract proposal. Then the submitter has no immediate recourse anyway because it has been approved. What the submitter has to do is to submit a new proposal to "revert" those changes. But I imagine the submitter won't want to immediately send the "revert proposal proposal"?
2. Submitter retracted right before control body approved. If the submitter retracted, I think it is fair game that the control body accepts not to "approve" the retracted proposal. Again I don't think there is any immediate recourse for the control body. Can the control body ask the submitter to re-submit? Maybe offline.

Thoughts?

[maccraymer]

I'll try to explain how I view all this as one who has been extensively using the current registry system for the last 5 years. Warning: this is a rather long-winded post!

In practice, there is no "race", at least for the ISOGR. The Control Body (CB) works together with the submitter who is either the authoritative source (AS) for the proposals or somebody acting on their behalf. In addition to the CB, the AS obviously has to approve their own proposed content to ensure the ISOGR contains authoritative information. That is the ISOGR's reason for being and it is now being enshrined in the 19127 revision. The AS therefore plays a major role in the CB’s decisions. If the AS wants to withdraw their proposal (what you call retract), the CB must abide by that and allow the proposal to be withdrawn. So, in practice, there would never be a “race” between the CB and the submitter (AS) because they are working together and making decisions together. So I think this discussion is moot as far as the ISOGR is concerned.

And just to clarify for own benefit, we have been discussing different kinds of actions here. There are the actions or proposals defined in 19135 that relate to register items (i.e., clarification, supersession, retirement, invalidation, redaction?) and there are actions or processes relating to the submission/acceptance/rejection of the above proposals (i.e., submitter submission, submitter withdraw, submitter appeal of rejections, RM acceptance, RM return to submitter, RM rejection, CB acceptance, CB return to submitter, and CB rejection). The proposal actions are defined in the new 19135 (Clause 3 and elsewhere) while the process actions are defined in Clauses 10.1 & 11.3 and Figs 22 & 23.

I see "return to submitter" and "withdraw" of a proposal as two completely different process actions by different entities for different reasons. First, the submitter should not be able to revise any proposal that has been submitted and accepted by the RM but I think it's fine for them to be allowed to withdraw it at any time before CB acceptance. For the ISOGR, that would be done in consultation with the CB as stated above. Consequently, there would be no "race" between CB approval and Submitter withdraw as explained above. If withdraw after submission is not allowed, the CB (in consultation with the submitter) would simply "return to submitter" and the submitter would then have the option of withdrawing their proposal if they choose. It just requires the extra "return to submitter" step. Either way gives the same result. Perhaps not allowing withdraws after submission is a "cleaner" way of doing it in general, and the best way for registers where the CB and submitter are not collaborating closely (i.e., the submitters are not necessarily authoritative sources). So I am leaning to NOT allowing proposals to be withdrawn by the submitter after it has been submitted. The submitter needs to wait for the CB or RM to return it to the submitter. However, there should be a way for the submitter to request the RM or CB "return" the proposal.

I also see no problem with nuking (completely removing) any withdrawn proposals. It's really up to the submitter to decide if they want to do that. If they want to revise the proposal, they simply do not withdraw it and wait for the RM or CB to "return" it, in which case the submitter can then revise it. Note that in the current registry, I am frequently withdrawing proposal groups that have been imported via spreadsheet. I nuke the previously imported proposal and resubmit the revised spreadsheet as a new proposal. I don't need or want to revise the proposal in the GUI because the spreadsheet is easier and more efficient. If we don't import spreadsheets and use the GUI alone to prepare & revised proposals, then I agree; withdrawing proposals would likely be infrequently used, except for testing in, e.g., the staging registry. However, I'm not convinced the GUI can provide the same convenience and efficiency as the spreadsheet but I'm open to being proven wrong ;-)

-Mike