fedora-pgm / pgm_docs

Clone
Source Code
GIT

#2 WIP: Add a proposed Feedback section
Merged 4 years ago by bcotton. Opened 4 years ago by bcotton.
change_feedback  into  master

file modified
+18 
@@ -60,6 +60,24 @@ 
 

  === Detailed Description
 

  Expand on the summary, if appropriate.
 

  A couple sentences suffices to explain the goal, but the more details you can provide the better.
 

+ If there are multiple reasonable approaches, you should indicate why you declined to use the others.
 

+ 

+ === Feedback
 

+ Summarize the feedback from the community and address why you chose not to accept proposed alternatives.
 

+ This section is optional for all change proposals, but is strongly suggested.
 

+ Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future.
 

+ If you get no feedback, that is useful to note in this section as well.
 

+ This section is inspired in part by the "Rejected Ideas" section described by https://www.python.org/dev/peps/pep-0001/#id46[PEP-0001].
 

+ 

+ For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal.
 

+ This could be done via a post to the devel mailing list for full community feedback, or sharing with some additional people who you trust to give you candid feedback.
 

+ //In thie future, there will be more specific guidance about how to post pre-proposal feedback.

What happened on this line?
(Is it meant to be commented out? Are double slash comments valid in AsciiDoc?)
Also, "thie".

 
+ Either way, when you receive feedback, you should summarize it in this section.
 

+ 

+ TIP: You should fill in this section as feedback is received.
 

+ As this is optional the Program Manager does not need to wait for you to complete this section before submitting to FESCo.
 

+ If the discussion gets heated, consider asking a neutral party to summarize the discussions for you.
 

+ This helps avoid bias and emotional response.
 

  

  === Benefit to Fedora

file modified
+1 
@@ -53,6 +53,7 @@ 
 

  |Owner|required|required
 

  |Current status|required|required
 

  |Detailed description|required|required
 

+ |Feedback|optional|optional
 

  |Benefit to Fedora|required|required
 

  |Scope/Proposal owners|required|required
 

  |Scope/Other developers|as applicable|required

This section would prompt Change Owners to explictly incorporate community feedback in the body of the proposal. This can be helpful to give a clear indication of why certain ideas were rejected both for history's sake and to expedite the FESCo voting process.

This section was suggested by churchyard with inspiration from Python's PEP-0001.

@churchyard here's a first draft for you. Does this match your expectations from our discussion?

Yes, this is pretty much it. (I also wanted to encourage ideas, but making it clear that ideas are not approved, but only discussed -- that is however a different problem to solve.)

From the text it is also unclear when should be the feedback section created. I suggest to add something like:

For innovative or possibly controversial ideas, consider collection feedback before you file the change proposal. Either way, when you receive feedback (both before or after the change was proposed), you should summarize it in this section. Sometimes, there is no feedback, and it is fine to acknowledge that here. Some other times, the discussions can get heated: consider asking a neutral party to summarize the discussions in such case to avoid bias.

Instead of the current

TIP: You should fill in this section as feedback is received.

1 new commit added

  • Add some more guidance for the controversial proposals as suggested by churchyard
4 years ago

Thanks for the feedback!

Yes, this is pretty much it. (I also wanted to encourage ideas, but making it clear that ideas are not approved, but only discussed -- that is however a different problem to solve.)

Agreed. I intentionally split this up so that we can handle them separately.

From the text it is also unclear when should be the feedback section created. I suggest to add something like:

I kept the TIP as-is, but I folded your suggested text into the section. Does this look reasonable to you?

I intentionally split this up so that we can handle them separately.

I thought so, but just wanted to make this clear in case the second part was somewhat lost. Thank you.

The change looks good.

Submitted to the devel list for public consumption

What happened on this line?
(Is it meant to be commented out? Are double slash comments valid in AsciiDoc?)
Also, "thie".

(Is it meant to be commented out? Are double slash comments valid in AsciiDoc?)

Yes, it is a valid AsciiDoc comment. It's an admission that I'm telling people to do something without providing much guidance.

Also, "thie".

WONTFIX typos in comments :smile:

rebased onto bdad3ff
4 years ago

Pull-Request has been merged by bcotton
4 years ago
Metadata
None
No Tags
Changes Summary 2
+18 -0
file changed
modules/ROOT/pages/changes_guide.adoc
+1 -0
file changed
modules/ROOT/pages/changes_policy.adoc
Powered by Pagure 5.14.1
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.