Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need firm definitions of pre-draft, draft, published #5

Open
danmcd opened this issue Oct 23, 2019 · 6 comments
Open

Need firm definitions of pre-draft, draft, published #5

danmcd opened this issue Oct 23, 2019 · 6 comments

Comments

@danmcd
Copy link
Member

danmcd commented Oct 23, 2019

There is no solid definitions of the IPD states. For example, one could assume:

Pre-draft: Still so WIP that readers should expect document changes in the short term.

Draft: Document is "good" and needs to be implemented. Could be changed only in the face of implementation/bringup experience.

Published: Document reflects running code.

For example, IPD 6 is in pre-draft state, but is much further along than, say, a skeletal IPD like IPD 11 is as of the time of this issue's filing. IPD 6 has open questions, but once answered is good to implement.

@rmustacc
Copy link
Contributor

pre-draft is meant to indicate that the author is working on it. Draft means that the document is ready for discussion with others. The publish state doesn't reflect whether or not running code exists, but there's been rough consensus. At least in my perspective.

@danmcd
Copy link
Member Author

danmcd commented Oct 23, 2019

Thank you, that's different than my sample assumption above, and IMHO should show up in the top-level README.md file.

@jclulow
Copy link
Member

jclulow commented Oct 23, 2019

I can put some language together to describe what I've been trying to orchestrate soon. Sorry for the ambiguity here!

The other thing I think is that getting to published state should require a sponsoring advocate, even if the IPD author is already an advocate themselves -- that way, at least one other person from the project leadership is signing off on things. The sponsor would also be signing on to assist with getting any required changes in front of the appropriate reviewers, assisting if required with drafting a test plan, etc.

@rmustacc
Copy link
Contributor

I think adding something to cover the fact that it's been implemented, which is something that Dan was suggesting above would be useful.

How do you feel about the term 'shepherd' for what you're describing as the sponser?

@danmcd
Copy link
Member Author

danmcd commented Oct 23, 2019

I like "shepherd".

I also want to make sure steps that cover inception (how much needs to be there before you enter predraft?), discussion (what differentiates predraft and draft in this space?), implementation (which can render plans/specs obsolete), and completion.

@rzezeski
Copy link
Member

Bump. Should we finally add a table to the README describing a) what the various state names are and b) what they mean? I'm happy to throw myself on the gears here and create a PR that you all shred to bits. Just seems like we really should have this bare minimum of definition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants