Meta proposal #50

bmbouter · 2017-02-13T19:37:42Z

No description provided.

mhrivnak · 2017-02-13T20:10:11Z

_proposals/pup-0001.rst

+^^^^^^^^
+
+Revision would occur as additional pull requests against the active proposal. This allows the full
+history of a proposal to always be maintained. This is how Python does it. This also allows


"full history", except for all of the email discussion. That's one part of this that I think is not ideal, that so much discussion would happen separate from the content being discussed.

There is a drawbacks section now which lists this drawback. There is also an alternatives section which includes some alternatives that do keep it in one place. Those two sections are also in the template so they needed to be added anyway. The email archive should make it easy to see the history. See what you think of this new revision.

daviddavis

Looks good @bmbouter. Thanks for creating this proposal. 👍

daviddavis · 2017-02-19T16:41:29Z

_proposals/pup-0001.rst

+Summary
+=======
+
+This proposal is designed to


Is this a TODO?

yes this was just not finished. I pushed a new version now.

daviddavis · 2017-02-19T16:46:00Z

_proposals/pup-0001.rst

+^^^^^^^^^^^^
+
+Once a proposal is merged to the proposals area, an announcement would be sent to pulp-dev, which
+would include a very brief introduction and a link to the proposal in its web viewable form.


You might want to add something about a PR being opened. Also maybe s/proposal/proposal pull request/.

I didn't do much with this, but I did list it as an alternative and an open question. I think I'm ready to adopt the pull request until decided on model which would be another small rewrite.

daviddavis · 2017-02-19T16:46:41Z

_proposals/pup-0001.rst

+
+General discussion would occur on the announcement thread via pulp-dev. Threaded e-mail readers
+should make this conversation format easy to follow, while keeping the one proposal document in-tact
+and easy to read.


I'm wondering if we should have the discussion at this point in the PR instead of on the mailing list. Thoughts?

This is a listed alternative in the proposal with the latest push. I'd like to get more input from others.

daviddavis · 2017-02-19T16:48:15Z

_proposals/pup-0001.rst

+come with a statement of objective concerns explaining what harm will come from adopting the
+proposal. -1 feedback should not be used to express subjective preferences. Note that votes can come
+from anyone, not just core devs. This is directly modeled after the Django process [3] who modeled
+their process after the Python and Apache communities.


We could use voting inside the Github PR:

How would the +0 and -0 work w/ this? I listed this as an alternative we should consider. I'd like to get more input from others. Maybe we should do this?

daviddavis · 2017-02-19T16:51:07Z

_proposals/pup-0001.rst

+
+    This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the
+    project to understand, and for somebody familiar with the codebase to implement. This should get
+    into specifics and corner-cases, and include examples of how the feature is used.


s/corner-cases/corner cases/

daviddavis · 2017-02-19T16:54:18Z

_proposals/pup-0001.rst

+  recast.
+* Core devs are expected to consider and echo serious feedback from the community especially any -1
+  votes from community members.
+* Consensus is not only possible. If obvious consensus is not reached, then the core devs decide.


Odd sentence: "Consensus is not only possible". Not sure what it's saying.

This has been fixed.

daviddavis · 2017-02-19T16:56:23Z

_proposals/pup-0001.rst

+Before Proposing
+^^^^^^^^^^^^^^^^
+
+Discussing an idea via the list prior to writing a formal proposal is encouraged. This is designed


Which list?

I pushed a new version which recommends using either pulp-list or pulp-dev depending on who would be affected. There are also bullet-point guidelines recommending which to use.

daviddavis · 2017-02-19T16:58:00Z

_proposals/pup-0001.rst

+Announcement
+^^^^^^^^^^^^
+
+Once a proposal is merged to the proposals area, an announcement would be sent to pulp-dev, which


I'm almost wondering if we should use pulp list if the proposed update affects end users?

Updated in new version

daviddavis · 2017-02-19T17:07:02Z

_proposals/pup-0001.rst

+"To Merge forward or not?".
+
+This is different than the communities we are modeling our process after. They use it for feature
+planning also, but I propose that we don't do that currently.


I think this is good for now but I could see us eventually using this system for things that are too big to be captured by a single user story/feature (e.g. "Support Ansible").

Content was rewritten for clarity on which mailing lists things should be sent to. Also some small fixes were made from feedback. New sections were added. These sections bring the proposal in line with the sections contianed within. The following new sections were added: * Drawbacks * Alternatives * Unresolved Questions

mhrivnak · 2017-02-25T19:04:57Z

_proposals/pup-0001.rst

+
+Proposals would be in restructured text format and sent as a pull request against the
+pulpproject.org repo or a dedicated repo. We could easily create a tab at the top of pulpproject.org
+to show off merged proposals. This could also be in a separate, dedicated repo like Python does, but


I suspect the simplest contributor experience would happen if there is a dedicated repo, a README at the root that summarizes how things work, and users can make PRs against master. That makes the "source" very easy to find and understand. I'm ok with any arrangement though.

I slightly favor putting proposals in the pulpproject.org repo.

mhrivnak · 2017-02-25T20:04:24Z

_proposals/pup-0001.rst

+The +1, +0, -0, -1 feedback process is used, with votes sent as responses via the
+announcement/discussion mailing list. The voting has the following meanings:
+
+* +1: "I love the idea and I’m strongly committed to it."


I suggest changing these to focus on evaluating the proposal itself, and not on the voter's feelings. I think that mindset makes it easier for a participant to fully consider all options, with as much impartiality as is reasonable. Something like:

+1: Will benefit the project and should definitely be adopted.
+0: Might benefit the project and is acceptable.
-0: Might not be the right choice, but is acceptable.
-1: Not the right choice and should definitely not be adopted.

Suggestions on the above are of course welcome.

Put another way, this change supports the idea that we should be participating as custodians of the project, looking out for the project's best long-term interests. Sometimes that might even require choices we don't like, but can recognize as the best path.

Updated in next push. I also removed the sentence reading Also, -1 feedback should not be used to express subjective preferences. since this wording makes that true for all vote types.

mhrivnak · 2017-02-25T20:08:31Z

_proposals/pup-0001.rst

+* If an obvious consensus arises via voting, the proposal is ratified. This is a bit vague, but it
+  works for the Django community.
+* Discussion on the thread can confirm if consensus is obvious or not.
+* Votes come from anyone, not just core devs


Add a period at the end of this sentence.

fixed in next push

mhrivnak · 2017-02-25T20:09:21Z

_proposals/pup-0001.rst

+* Votes come from anyone, not just core devs
+* A -1 from a core dev is considered a veto vote and will block ratification until the vote is
+  recast.
+* Core devs are expected to consider and echo serious feedback from the community especially any -1


Add a comma after "community".

fixed in next push

mhrivnak · 2017-02-25T20:10:15Z

_proposals/pup-0001.rst

+  works for the Django community.
+* Discussion on the thread can confirm if consensus is obvious or not.
+* Votes come from anyone, not just core devs
+* A -1 from a core dev is considered a veto vote and will block ratification until the vote is


Should we define a "core dev" somewhere in this doc?

If so, maybe that would be defined as someone with commit permission to the Pulp source?

Good idea; I added a glossary section with this term and it is referred to from all references of "core dev".

mhrivnak · 2017-02-25T20:28:06Z

_proposals/pup-0001.rst

+    Alternatives
+    ============
+
+    What other designs have been considered? What is the impact of not doing this?


I would add some encouragement here, along these lines:

Be creative. Brainstorm. No idea is too outlandish to mention. Include ideas that are "obviously" bad; even one sentence about why something was ruled out is valuable.

This section is expected to include a diligent accounting of options. Additions will be requested if it does not demonstrate sufficient diligence.

good addition; it's included in the next push

mhrivnak · 2017-02-25T20:29:07Z

_proposals/pup-0001.rst

+Why Approve/Reject This Way?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* It treats community decision making (not just core dev decision making) as a first class principle


Add periods to each line to be consistent with sections above.

fixed in next push

mhrivnak · 2017-02-25T20:29:30Z

_proposals/pup-0001.rst

+
+* It treats community decision making (not just core dev decision making) as a first class principle
+* It works for the best communities we know of (Django, Python, Apache, etc)
+* It allows people to be as involved or not as they way


s/way/want/

fixed in next push

mhrivnak · 2017-02-25T20:32:43Z

_proposals/pup-0001.rst

+
+* The proposal index is updated moving it from an active section to an approved area. This is
+  similar to the index of PEPs for Python.
+* A post-approval announcement should be sent in the same thread as the initial announcement and


A new thread for the announcement would be valuable. Most readers are likely to eventually tune out a long discussion about details of a proposal they don't feel strongly about. They could easily miss the announcement if it's part of that thread.

I agree, I updated the proposal to reflect this.

* Adds a Footnotes section * Updates the meaning of the votes from feedback * Grammar fixes * Adds post-approval announcement to be in a new thread

daviddavis · 2017-02-28T19:52:13Z

Looks good. One thing I noticed though is that you seem to have markdown style links in your proposal which is reStructuredText.

seandst · 2017-03-01T00:17:37Z

_proposals/pup-0001.rst

+Finding/Discovering Proposals
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An index mimicking [the Python one](https://www.python.org/dev/peps/) would be created which would


s/one/PEP index/ ?

fixed in next push

seandst

One minor typo and one structural change in the proposal template.

seandst · 2017-03-01T00:21:08Z

_proposals/pup-0001.rst

+
+* This is very developer focused. Everyone knows how use emails and a web browser. Not everyone
+  knows how to use Github review.
+* The proposal never being merged to a Pulp repo may cause us to loose access to previous proposals.


s/loose/lose/

fixed in next push. The section was removed actually.

seandst · 2017-03-01T00:27:47Z

_proposals/pup-0001.rst

+    title: <title goes here>
+    author: <author or authors named>
+    ---
+


Somewhere around here, maybe in the Summary block, maybe by using metadata at the top, should be a templated section that details the PUP status, like python PEPs. The section should include the current approval state, and could also include created/updated timestamps.

I'll happily mess with jekyll and put something together if you want me to, just let me know.

I added a created: dd-mmm-yyyy and status: [Active|Approved|Rejected|Abandoned] attributes to the frontmatter. It's in the template and also in this PUP itself.

seandst · 2017-03-01T00:30:03Z

_proposals/pup-0001.rst

+Unresolved Questions
+====================
+
+What are we calling it? (PUP, PCP, <your idea here>)


I like PUP, and it looks like you do, too.

Let's take PUP, because PCP stands for acronym of some heavy drug

PUP it is. The next revision has been rewritten to use this for consistency.

seandst · 2017-03-01T00:31:01Z

_proposals/pup-0001.rst

+====================
+
+What are we calling it? (PUP, PCP, <your idea here>)
+Is 10 calendar days the right decision making time default.


I think I'd prefer two weeks, but agree that making this much longer would be counter productive.

12 days it is. Updated on next push.

seandst · 2017-03-01T00:31:09Z

_proposals/pup-0001.rst

+Footnotes
+=========
+
+.. [#f1] A core dev is anyone with the commit bit to the [platform repo](https://github.com/pulp/pulp/).


s/the commit bit/permission to commit/ ?

fixed on next push

seandst · 2017-03-01T00:32:23Z

_proposals/pup-0001.rst

+    Unresolved Questions
+    ====================
+
+    What parts of the design are still TBD?


Is it worth spelling out "to be determined" to the benefit of folks that might not be familiar with this abbreviation?

yes, fixed in next push.

bmbouter · 2017-03-11T01:39:13Z

@daviddavis I switched the filetype to a .md file and updated the text to indicate it should use markdown. Thanks for pointing it out.

* The name PUP is now used. * PUPs will live as pull requests until a decision is made. * A dedicated repo will now be used instead of pulpproject.org. * Voting uess a minimum of 12 days instead of 10. * The alternative of using Github for feedback is removed because feedback is now allowed directly on the pull request in addition to the mailing list. * The alternative of keeping PUPs as pull requests has been adopted and has been removed from the alternatives section. * Several minor grammer and wording edits.

bmbouter · 2017-03-16T20:43:49Z

I implemented many changes discussed. One of them was to create a dedicated repo which I did. As such this PR needs to be closed in favor of this one: pulp/pups#1

Meta proposal

cbb3c95

mhrivnak reviewed Feb 13, 2017

View reviewed changes

daviddavis suggested changes Feb 19, 2017

View reviewed changes

bmbouter force-pushed the meta-proposal branch from 7f10035 to 77257f5 Compare February 24, 2017 22:00

bmbouter force-pushed the meta-proposal branch from 77257f5 to 8bd174f Compare February 24, 2017 22:07

Fixing bulleted lists in the Alternatives section

425bb10

mhrivnak reviewed Feb 25, 2017

View reviewed changes

Updates from feedback

c3eebc5

* Adds a Footnotes section * Updates the meaning of the votes from feedback * Grammar fixes * Adds post-approval announcement to be in a new thread

seandst reviewed Mar 1, 2017

View reviewed changes

seandst suggested changes Mar 1, 2017

View reviewed changes

seandst reviewed Mar 1, 2017

View reviewed changes

daviddavis approved these changes Mar 1, 2017

View reviewed changes

bmbouter closed this Mar 16, 2017

bmbouter deleted the meta-proposal branch March 16, 2017 20:45

Meta proposal #50

Meta proposal #50

Conversation

bmbouter commented Feb 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daviddavis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seandst Mar 1, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmbouter Feb 27, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daviddavis commented Feb 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seandst left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmbouter Mar 11, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmbouter commented Mar 11, 2017

bmbouter commented Mar 16, 2017 • edited

seandst Mar 1, 2017 •

edited

bmbouter Feb 27, 2017 •

edited

bmbouter Mar 11, 2017 •

edited

bmbouter commented Mar 16, 2017 •

edited