churchyard suggested we add a "Feedback" section to the Change proposal template[1]. I see two benefits to this:
1. It provides FESCo a useful summary of the community feedback (and in particular the reasoning behind rejecting alternatives) to simplify the voting process 2. It improves the historical record so that future Fedorans can understand why a change was implemented in a particular way and not another
I have drafted proposed edits[2] to the Changes documentation that would add an optional Feedback section to the template. I am opening this up for community discussion before submitting it to FESCo for approval.
The reason we chose to go with making this optional is that making it mandatory would necessarily add additional wait time before proposals are sent to FESCo. And also it's better to ease people into the idea. :-)
[1] https://fedoraproject.org/wiki/Changes/EmptyTemplate [2] https://pagure.io/fedora-pgm/pgm_docs/pull-request/2
On Tue, May 05, 2020 at 03:28:25PM -0400, Ben Cotton wrote:
churchyard suggested we add a "Feedback" section to the Change proposal template[1]. I see two benefits to this:
- It provides FESCo a useful summary of the community feedback (and
in particular the reasoning behind rejecting alternatives) to simplify the voting process 2. It improves the historical record so that future Fedorans can understand why a change was implemented in a particular way and not another
I have drafted proposed edits[2] to the Changes documentation that would add an optional Feedback section to the template. I am opening this up for community discussion before submitting it to FESCo for approval.
The reason we chose to go with making this optional is that making it mandatory would necessarily add additional wait time before proposals are sent to FESCo. And also it's better to ease people into the idea. :-)
I like the idea. Some proposals already include sections like that, but it is always better to have this in a standarized layout. Some people won't bother, but that's OK too.
Zbyszek
I don't know, I am somewhat ambivalent on this. I am not sure who is going to collect the feedback there. Will it be the owner of the change or somebody else? What will be the structure? Will it be just bunch or quotes from random sources?
Wouldn't it be better to utilize the "discussion" tab/feature of the wiki instead?
Or wouldn't it be better to include the devel ML reference?
Vít
Dne 05. 05. 20 v 21:28 Ben Cotton napsal(a):
churchyard suggested we add a "Feedback" section to the Change proposal template[1]. I see two benefits to this:
- It provides FESCo a useful summary of the community feedback (and
in particular the reasoning behind rejecting alternatives) to simplify the voting process 2. It improves the historical record so that future Fedorans can understand why a change was implemented in a particular way and not another
I have drafted proposed edits[2] to the Changes documentation that would add an optional Feedback section to the template. I am opening this up for community discussion before submitting it to FESCo for approval.
The reason we chose to go with making this optional is that making it mandatory would necessarily add additional wait time before proposals are sent to FESCo. And also it's better to ease people into the idea. :-)
[1] https://fedoraproject.org/wiki/Changes/EmptyTemplate [2] https://pagure.io/fedora-pgm/pgm_docs/pull-request/2
I'm not the author of the proposal, but my take on this:
On Wed, May 06, 2020 at 10:02:19AM +0200, Vít Ondruch wrote:
I don't know, I am somewhat ambivalent on this. I am not sure who is going to collect the feedback there. Will it be the owner of the change or somebody else? What will be the structure? Will it be just bunch or quotes from random sources?
Yes, the idea is that the author(s) of the change or some people working in coordination with the authors will collect and succinctly summarize feedback and the rejected options.
Wouldn't it be better to utilize the "discussion" tab/feature of the wiki instead?
It's much less visible and the idea is to have items summarized. This is in parallel to the Change itself: we want the Change page to be self-contained, and we don't just refer the reader to the discussion on the mailing list. The Change page is adjusted to incorporate feedback.
Or wouldn't it be better to include the devel ML reference?
The ML reference is added automatically by FPM, but our threads are often very long and circuitous.
Zbyszek
On Wed, May 6, 2020 at 4:03 AM Vít Ondruch vondruch@redhat.com wrote:
I don't know, I am somewhat ambivalent on this. I am not sure who is going to collect the feedback there. Will it be the owner of the change or somebody else?
The owner of the change would be responsible for it, but they may delegate that to someone for contentious issues as described in the proposed text. In an ideal world, I would love to have someone with journalism-like experience whose job was to perform this kind of summary (and perhaps summaries of our mailing lists more generally). I don't see that happening.
What will be the structure? Will it be just bunch or quotes from random sources?
It could be, although the idea is to have a curated summary. I don't want to prescribe a format, at least not until we have some experience with this, because the feedback summary could range from "no one provided feedback" to "here are the 20 objections people had and how we responded to them". That said, if anyone has some examples of proposals (either in Fedora or other projects) that do a good job of summarizing feedback, I'd be happy to add those as references in the guidance.
Wouldn't it be better to utilize the "discussion" tab/feature of the wiki instead?
We could do that, but including it in the text itself makes it more portable if the change gets republished somewhere else (say, for example, we move from Mediawiki to another wiki platform or we archive accepted change proposals as static pages).
Or wouldn't it be better to include the devel ML reference?
For simple feedback, that would be sufficient. For long threads, it adds little value. I do include a link to the thread when submitting changes to FESCo, but it would be helpful to have a quick summary to read instead of re-reading the whole thread (and yes, someone could write the summary to intentionally misrepresent the feedback, but I trust the community to act in good faith).
On 06. 05. 20 16:31, Ben Cotton wrote:
On Wed, May 6, 2020 at 4:03 AM Vít Ondruchvondruch@redhat.com wrote:
I don't know, I am somewhat ambivalent on this. I am not sure who is going to collect the feedback there. Will it be the owner of the change or somebody else?
The owner of the change would be responsible for it, but they may delegate that to someone for contentious issues as described in the proposed text. In an ideal world, I would love to have someone with journalism-like experience whose job was to perform this kind of summary (and perhaps summaries of our mailing lists more generally). I don't see that happening.
BTW LWN does a great job at summarizing devel list discussions.
https://lwn.net/Articles/805180/ https://lwn.net/Articles/792718/ https://lwn.net/Articles/811369/ https://lwn.net/Articles/817426/ https://lwn.net/Articles/729366/
(Random sample where I am involved.)
On Wed, May 06, 2020 at 04:53:58PM +0200, Miro Hrončok wrote:
On 06. 05. 20 16:31, Ben Cotton wrote:
On Wed, May 6, 2020 at 4:03 AM Vít Ondruchvondruch@redhat.com wrote:
I don't know, I am somewhat ambivalent on this. I am not sure who is going to collect the feedback there. Will it be the owner of the change or somebody else?
The owner of the change would be responsible for it, but they may delegate that to someone for contentious issues as described in the proposed text. In an ideal world, I would love to have someone with journalism-like experience whose job was to perform this kind of summary (and perhaps summaries of our mailing lists more generally). I don't see that happening.
BTW LWN does a great job at summarizing devel list discussions.
https://lwn.net/Articles/805180/ https://lwn.net/Articles/792718/ https://lwn.net/Articles/811369/ https://lwn.net/Articles/817426/ https://lwn.net/Articles/729366/
(Random sample where I am involved.)
We can add a link to the lwn article (when there's one for some change) or to other distros when they do something similar in the feedback section too.
Zbyszek
On Tue, May 05, 2020 at 03:28:25PM -0400, Ben Cotton wrote:
churchyard suggested we add a "Feedback" section to the Change proposal template[1]. I see two benefits to this:
- It provides FESCo a useful summary of the community feedback (and
in particular the reasoning behind rejecting alternatives) to simplify the voting process 2. It improves the historical record so that future Fedorans can understand why a change was implemented in a particular way and not another
I have drafted proposed edits[2] to the Changes documentation that would add an optional Feedback section to the template. I am opening this up for community discussion before submitting it to FESCo for approval.
The reason we chose to go with making this optional is that making it mandatory would necessarily add additional wait time before proposals are sent to FESCo. And also it's better to ease people into the idea. :-)
[1] https://fedoraproject.org/wiki/Changes/EmptyTemplate [2] https://pagure.io/fedora-pgm/pgm_docs/pull-request/2
Seems fine to me as long as it's optional. Also might be we should note it was assembled by the change owner(s) or Other (if not change owners).
Just reading back someone might assume a disinterested AI assembled the section, when it was made by fallable humans who might have missed something, put a better 'spin' on it or whatever. As long as it's disclosed I think thats fine.
kevin