Standard & API writing order

[oeed]

Although I had originally stated that the API should be written before the pull request is made I'm not so sure it's the right process. Instead I think that the API should be written after the standard has approval. The PR can then have a awaiting api label assigned to it along with accepted.

[viluon]

In that case, I'd suggest that the author should submit 2 PRs, one with the proposal (proposal) (which won't be merged, but you need to store the associated Markdown docs somewhere) and when that's accepted,(s)he submits another one (standard) with the actual standard and utilities.

[viluon]

What do you think of that @oeed ?

[oeed]

Hmm, actually that might work. Although, it separates things a bit too much I feel.

[viluon]

Agreed, although cross-referencing the PRs might help with that..

[lyqyd]

What's the need for a second PR? May as well make any necessary changes on the initial one, and simply not pull until it's ready. I'm having trouble seeing what the added benefit is to using a separate PR for the final standard text.

[oeed]

Yeah I'd agree with @lyqyd, @viluon.

[viluon]

Well, I know that 2 PRs is silly @oeed, but as it sort of "works" now, people open PRs when they've got nothing completed really... I'd like to fix that, just don't know how.

[oeed]

I don't see a huge issue with the current PRs. Sure, it'd be nice if we could merge them faster, but placing too many barriers will just deter people from contributing.