p1025r1 and Paper Storage Refactor

[ThePhD]

This pull request adds p1025r1 to the repository. It also makes a new folder -- "published" -- that helps provide the frozen / submitted versions of papers, leaving the general "papers" folder to be a staging area.

[steve-downey]

P1025 looks good to me. I agree with gutting the discussion of Unicode consortium standards in light of Core feedback. Great job!

[tahonermann]

How would you feel about keeping published papers under papers and adding a papers/drafts directory for storing drafts? I know we spend more time with drafts, but this seems better to me from a long term organizational perspective.

[tahonermann]

How would you feel about keeping published papers under papers and adding a papers/drafts directory for storing drafts? I know we spend more time with drafts, but this seems better to me from a long term organizational perspective.

Expanding on this; I suspect drafts will typically live in forks of the repo. Perhaps there is little motivation for separating published papers and drafts.

[mzeren-vmw]

how about top level

/papers /drafts

I think it's ok to have drafts in master. For one thing git log drafts gives you a way to research history.

From: Tom Honermann notifications@github.com Reply-To: sg16-unicode/sg16 reply@reply.github.com Date: Saturday, June 9, 2018 at 5:18 PM To: sg16-unicode/sg16 sg16@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [sg16-unicode/sg16] p1025r1 and Paper Storage Refactor (#18)

How would you feel about keeping published papers under papers and adding a papers/drafts directory for storing drafts? I know we spend more time with drafts, but this seems better to me from a long term organizational perspective.

Expanding on this; I suspect drafts will typically live in forks of the repo. Perhaps there is little motivation for separating published papers and drafts.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/sg16-unicode/sg16/pull/18#issuecomment-395999558, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACODKCP5n-jYck-MVu-Ko3F_gVY5EXbVks5t7DuMgaJpZM4UeK96.

[ThePhD]

I wanted to separate drafts / published as a means of keeping it easy to refer to r0/r1/rX of papers we make, since (in particular) Core wants papers that are drafts to be dXXXXrX numbered, and published versions to be pXXXXrX numbered.

Like, published is the staging area for "we are going to submit this / it has been approved", and also lets others know that paper X is something we are serious about. ... In which case it's a good way to signal that reading and/or drive-by edits are a Good Thing™.

I'm more than happy to do it the other way, though. (Though, perhaps my decision is informed that sometimes I like to delete my branch when I'm done. ;;)

[steve-downey]

I think the experience with D1025r1 is illustrative. There is a period of time where we are coöperating on a draft before it is finalized. There is a strong directive that there should not be accessible documents with a P or N number that are not the actual document, in order that there be clarity on what is being considered and what was approved. Now, there is an understanding that a doc can be changed, and resubmitted, without changing the R number, pre mailing, or on wiki during a meeting.

I think papers vs drafts is good. I think early drafts are good. Papers should reflect the last version sent to be published. Drafts can live on master while we are working on them. Edits to a P or N should be on a branch.

[tahonermann]

how about top level

• /papers
• /drafts

I'd prefer to keep both under a common directory.

There is a strong directive that there should not be accessible documents with a P or N number that are not the actual document, in order that there be clarity on what is being considered and what was approved.

Indeed. The very last change made to a document before it is submitted for a mailing should be to swap the 'D' for a 'P' in the document header and to rename the file accordingly. Once submitted, the document should be considered immutable.

I'm happy with using the repo to collaborate and coordinate on drafts. In my earlier comment, my intent was to say that I expect drafts to start their lives in forks. I didn't intend to say that they should stay there (though the words I used clearly give that impression).

My standard practice (see https://github.com/tahonermann/std-proposals) is to keep drafts and papers in the same directory. I find it useful to to have the revisions side-by-side for diff related purposes and for seeing which published papers have new active drafts.

@ThePhD I'm not sure I followed your comments. It sounds to me like file naming conventions ('dXXXXrY' vs 'pXXXXrY') would suffice. Unless you are worried about a single directory getting quite cluttered?

[mzeren-vmw]

I'd prefer to keep both under a common directory.

My standard practice (see https://github.com/tahonermann/std-proposals) is to keep drafts and papers in the same directory. I find it useful to to have the revisions side-by-side for diff related purposes and for seeing which published papers have new active drafts.

All in the same directory sounds good to me.

[ThePhD]

I moved everything to the flat structure, since I don't have the strongest preference ever about it, really: the pXXXX/dXXXX split is likely more than enough!

[tahonermann]

Thanks, JeanHeyd. Two more questions:

Changes to P1025R0 are included. Unless I'm mistaken, the copy of P1025R0 present in the repo is already an exact match of the submitted P1025R0 and therefore shouldn't be changed.

The changes include both a D1025R1 and P1025R1. I think we should only have one of these (at any given time). Further, the P1025R1 should be an exact match to http://wiki.edg.com/pub/Wg21rapperswil2018/StrawPolls/p1025r1.html?twiki_redirect_cache=c09d4c8f65963b767fb36599807b5ec1 (which may be the case, I didn't check).

I'm assuming that P1025R1 hasn't already been submitted for the post-meeting mailing or, if it has, it exactly matches the one at the link above.

I'm inclined to do the following: 1) Decline this PR. 2) Checkin the P1025R1 version from the wiki link above.

Would this get us to the state we want to be in?

[rmartinho]

Argh, idiot me. I should have read this. @tahonermann If you want to go that way, which I agree with, I opened #19 (and closed and reopened, but that's just silliness).

[tahonermann]

I went ahead and merged #19 as provided by @rmartinho, so I'm closing this PR without having merged it now. @ThePhD, if there are additional changes in the D1025R1 draft you provided relative to P1025R1 from the wiki, let's discuss whether we need those.

[ThePhD]

I like it as it was merged in #19 👍