Subject: Re: [TOOLS-DEVELOPMENT] Fwd: [Tools-discuss] Raw 1st draft: SoW for improvements to the manual submission process

From: Robert Sparks <[email-masked]>
Date: Wed, 12 Aug 2015 09:41:59 -0500

I don't think I've gotten any comment on this proposed SoW.
If you've given me any (especially verbally) and I've forgotten, please 
retransmit.
Otherwise, is this ready to ship?

RjS

On 7/10/15 1:52 PM, Robert Sparks wrote:
> I got bitten by a bad autocomplete again.
> This (development) is where I really meant to send this.
>
> RjS
>
>
> -------- Forwarded Message --------
> Subject: 	[Tools-discuss] Raw 1st draft: SoW for improvements to the 
> manual submission process
> Date: 	Fri, 10 Jul 2015 11:00:48 -0500
> From: 	Robert Sparks <[email-masked]>
> To: 	Tools Team Discussion <[email-masked]>
>
>
>
> The transparency of the ID submission process needs to be improved,
> particularly for those submissions that are handled directly by the
> secretariat ("manual" and "forced" submissions).
>
> When an author uses the datatracker submission tool, SubmissionEvents
> are captured, noting when the draft was submitted, when it was approved
> by previous authors (and by who), when it was approved by a WG chair if
> such approval was necessary, and when it was posted into the
> repository. Currently, the document’s history shows only that a new
> version is available.
>
> The submission tool presents an option to authors to request that the
> secretariat finish the submission process. The datatracker captures the
> candidate document and sends email to the secretariat. Often the
> request is made because the submission tool was unable to extract the
> correct meta-data from the document. In this case, the secretariat
> populates the meta-data, and forces the post. In other cases, there are
> issues identified by id-nits that the secretariat helps diagnose, and
> the author is guided through fixing the issues and restarting the
> submission process with a repaired document. Again, SubmissionEvents
> are captured as the document goes through this process, but for drafts
> that are forced, the document history does not reflect these events.
>
> The secretariat also receives requests to post a draft by direct email,
> bypassing the submission tool altogether. (Currently, the secretariat
> receives around 10 such requests each meeting cycle). The secretariat
> operates the submission tool on behalf of the author. The
> SubmissionEvents currently captured do not reflect that this was a
> manual submission request.
>
> The secretariat currently relies on a combination of RT and personal
> email archives to keep track of the outstanding manual submission
> requests.
>
> This project will make the following improvements:
>
> When a document is posted via the normal submission process, DocEvents
> reflecting the SubmissionEvents for the initial submission, the
> approval of previous authors, and the approval of a stream authority
> (such as WG chairs for a WG -00) will be added to the document. That
> is, where documents currently typically have a first history entry of
> "New version available: whatever-00", The first entries will be "New
> version submitted", "New version approved by previous author: (name)",
> "WG -00 approved by (name)", "New version available: whatever-00". The
> entries for subsequent versions are analogous.
>
> When manual submission is requested via the submission tool, and the
> document is posted by the secretariat, DocEvents reflecting that the
> manual posting was requested, any approvals obtained, and that the
> document was forced will be added to the document.  An example of the
> entries would be  "Manual submission requested by (name)", "Meta-data
> set to <metadata> by (name)", "WG -00 approved by (name)", "New version
> available: whatever -00".
>
> When manual submission is requested by direct email, the secretariat
> will have the ability to tell the tracker that the request was received
> and upload the document from the email request, but not handle the
> request immediately. After this indication, the document will be in the
> same condition as a document requesting manual submission via the
> submission tool.
>
> However the secretariat should not be forced to take that extra step if
> the request will be processed immediately. The submission tool should
> be modified to allow the secretariat to indicate they are submitting
> the document on behalf of an author at their request for manual
> submission. SubmissionEvents indicating that manual submission was
> requested will be created. Once the document is posted, DocEvents
> reflecting the history of the submission (as described for the above
> cases) will be created.
>
> A page will be created (readable by anyone) that shows the set of
> outstanding manual submission requests. Each entry will either show, or
> provide navigation to a separate page that shows, the SubmissionEvent
> history for the outstanding submission. When logged in as the
> secretariat, there will be easy navigation from each entry to the page
> that allows processing the request.
>
> Note that as of release 6.0.4, the manual submission process results in
> a DocEvent that says simple "New version available" without providing a
> link to the version that became available.  This project will ensure
> that all paths that produce a "New version available" DocEvent include
> a link to the new version in the event’s description.
>
> -- 
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org bugs athttp://tools.ietf.org/tools/ietfdb
> Please report tools.ietf.org bugs athttp://tools.ietf.org/tools/issues  or
> send email [email-masked]
>
>