[core-workflow] PEP awareness statistics

[anatoly techtonik]

Sorry for a long delay. I can't ignore Nick's opinion, but I leave it
into separate
mails, because it raises two issues that are off subject for current thread (and
hijack it). However, I'd like to thank him for his personal choice of
leaving the
freedom to express opinion to me. I am not as evil as it looks like, so at some
point it will be possible to get back to dialog.


Back to the idea of replacing feedback controls with more simple buttons.
There is no data, but I think that people who understand what these controls
are for, and who cared to read PEP till the end, will use them properly no
matter how many controls there are. This is the most accessible way how can
they communicate the feedback.

I am not sure about quick ratings. What message does a rating carry?
1-5 - is it a quality of PEP, its clarity, or a general rating of the
idea of PEP?
It doesn't tell much neither to me, as a voter, not to me, as a writer.

Yes/No is extreme, but surprisingly, a good choice for simplicity. PEP fixes
things in stone, so saying No is a clear indication that there are moments you
disagree with. Making it personal makes it possible to find and ask why, but
it is a hassle, so better leave a way to leave feedback immediately.

About comments.

Comment is an obvious way to go, but comments are not editable and you
won't be able to change an opinion later. Editable personal note, which is not
a comment, might be a better choice. I see two kind of notes. Both of them
probably public, but one - let's call this `opinion` on version - is
used to gather
overall impression of response to PEP. Another type of not - let's call it
personal `status` note - this carries notes for yourself that are important
during PEP review (and would be nice if those were backed up by operational
transformation stuff like Etherpad-lite, so that when you're interrupted in the
middle and forgot to save, your information is not lost).

For simplicity, however, this can be replaced by a simple message. Ideally
message form can come with its own feedback loop, which is in its most
simple form a pointer to this group and an explanation note that usefullness
and usability of the feedback process over PEP is researched, discussed
and developed here, so feedback on that is also welcome.


On Tue, Aug 26, 2014 at 5:46 PM, Guido van Rossum <guido at python.org> wrote:
> I like the idea of adding feedback buttons to the website (not just the
> PEPs). I'm not sure how much you can get people vote with that much though.
> Maybe just a yes/no (like MSDN does) or a star-rating (1-5)?
>
>
> On Tue, Aug 26, 2014 at 2:48 AM, anatoly techtonik <techtonik at gmail.com>
> wrote:
>>
>> Hi,
>>
>> In order to improve workflow it is important to collect data about
>> the process. Even if Python doesn't have any kind of democracy,
>> meritocracy or other kind of political system (well, dictatorship?),
>> it is nice to estimate how many people are really involved in the
>> process of language evolution.
>>
>> For example, there is a new accepted PEP 440 which is
>> authored by two people (documented in PEP), and they are
>> are listed in credits. They definitely put a lot of work in making it
>> happen. Other people had less chances to monitor the progress,
>> and in my opinion this is the reason why handling semantic
>> versioning was not given enough attention - proposing to convert
>> versions instead of specifying mechanism for packages to
>> specify alternative versioning system:
>> http://legacy.python.org/dev/peps/pep-0440/#semantic-versioning
>>
>> But, my opinion is an opinion and it will stay so until it is backed
>> up by data that can put some weight to my words. This can be
>> possible if PEP pages allowed people with registered accounts
>> to provide structured feedback for PEP in a form of three metrics:
>>
>>    % of text read     - 0 .. 100% (approximate)
>>    Text clarity         - 0 .. 5        (how hard to understand the text)
>>    PEP coverage     - 0 .. 5       (does the PEP cover your case well)
>>    Accept / Reject / Clarify / meh.
>>    Optional (reason/comment):
>>
>> --
>> anatoly t.
>> _______________________________________________
>> core-workflow mailing list
>> core-workflow at python.org
>> https://mail.python.org/mailman/listinfo/core-workflow
>> This list is governed by the PSF Code of Conduct:
>> https://www.python.org/psf/codeofconduct
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)



-- 
anatoly t.