Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

2019-05-24 Thread Ezio Melotti
On Fri, May 24, 2019, 23:14 Gregory P. Smith  wrote:

>
>
> On Fri, May 24, 2019 at 1:48 PM Ezio Melotti 
> wrote:
>
>>
>> On Fri, May 24, 2019, 20:23 Gregory P. Smith  wrote:
>>
>>> -cc: committers to avoid crossposting.
>>>
>>
>> +1 (I wanted to include committers, since the announcement about PEP 581
>> was posted there too, but it's better to keep the discussion here)
>>
>>
>>> I have feedback for roundup as experienced on BPO that should be
>>> represented within PEP 595 if we are going to have a summary of "improving
>>> roundup for BPO" captured in a PEP (presumably already rejected given 581?
>>> But good to have documented regardless so _thank you_ for doing this
>>> writeup even though I realize our plan of record may be demoralizing for
>>> you).
>>>
>>
>> We would like people to re-evaluate the decision, but if that doesn't
>> happen I think the PEP is still useful, since it provides a fair view of
>> Roundup capabilities and discusses things that we will have to take into
>> account if we proceed with the migration -- that's why we decided to go
>> ahead and write the PEP.
>>
>>
>>> > **Flexible UI.**  While Roundup UI might look dated, it is convenient
>>> and flexible.
>>>
>>> I wholly disagree with this statement.
>>>
>>
>>> The BPO roundup UI drives me nuts. every. single. time. I have to use
>>> it.  It is not optimized for common workflows users actually need to
>>> accomplish when using a bug tracker.  Two example usability issues (of
>>> many): Users can't read the latest update to a bug of length because it is
>>> hidden within the *middle* of the scrolling region, they must hunt for it.
>>>
>>
>> This came up in the past, and two solutions have been proposed already:
>> 1) keyboard shortcuts have been added in the issue page to quickly jump
>> to the first/previous/next/last message and to the response box [0].  They
>> support both mnemonic (f/p/n/l/r) and vim-style (h/k/j/l/i) combinations.
>> You can find a summary table in the left sidebar of the issue page, under
>> help -> keyboard shortcuts.
>> 2) a patch to collapse the history by default (so that the last message
>> was at the end of the page) was proposed and merged [1], but it was
>> reverted after a few days because some devs wanted direct access to the
>> history without having to do an extra click every time to expand it.
>>
>> After reading, the text box to add to the discussion is oddly located
>>> near the *top* of the scrolling region so that a user cannot see context of
>>> a bug discussion they are responding to as they type.
>>>
>>
>> This has also been discussed and different people had different opinion.
>> Some suggested to reverse the order of the messages so that the last
>> message is at the top near the reply box (like Twitter does), but other
>> said it's unnatural to read.  Some suggested to put the reply box at the
>> bottom; however if the other fields are left at the top you would have to
>> go back up to set them, and if they are moved down you won't easily see
>> them at the top when you open an existing issue.  Another solution is
>> duplicating the fields and response box at the top and bottom.
>>
>
> The two other modern bugtracker UIs I use on a regular basis do this by
> having all such non-conversation metainfo in a persistent top and side bar
> boxes such that it is always present.  Keeping the conversation and
> metainfo changes listed in order (latest message at the bottom, metainfo
> deltas interspersed in between messages all ordered/grouped by timestamp,
> and reply text entry box below that.  These two are typically big-screen
> engineering UIs (github being one of them), if mobile is desired i expect
> these would effectively wind up as a multi-pane UI.  There's a third ticket
> that I use for non-engineering stuff which does things in reverse order
> with the text entry up top and messages in reverse chronological order
> below that.  This reversal always annoys me; probably because I spend most
> of my time in the others so it forces me to do headstands. I don't know if
> there is a *right* answer between the two approaches, I just know what I
> prefer. But the common theme is keeping new the update UI elements right
> next to the most recent entries which is what BPO lacks today.
>
> What I mean with *flexible* when I wrote the PEP, is that, unlike GitHub
>> (where they decide), we can customize bpo however we want (as long as we
>> agree on what we want -- we could even have per-user settings if we really
>> want to :)
>>
>
> Definitely true in that sense.  Custom things, no matter where, are custom
> code.  diverge from an upstream project in our own fork and maintenance and
> updates become harder.  Author a pile of bots to automate tasks within a
> standard API or UI (as is working great for our Github PR workflow) and the
> equivalent maintenance burden falls on keeping the bots working.
>

To clarify, Roundup allows you by design to define instances where you can
customize 

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

2019-05-24 Thread Gregory P. Smith
On Fri, May 24, 2019 at 1:48 PM Ezio Melotti  wrote:

>
> On Fri, May 24, 2019, 20:23 Gregory P. Smith  wrote:
>
>> -cc: committers to avoid crossposting.
>>
>
> +1 (I wanted to include committers, since the announcement about PEP 581
> was posted there too, but it's better to keep the discussion here)
>
>
>> I have feedback for roundup as experienced on BPO that should be
>> represented within PEP 595 if we are going to have a summary of "improving
>> roundup for BPO" captured in a PEP (presumably already rejected given 581?
>> But good to have documented regardless so _thank you_ for doing this
>> writeup even though I realize our plan of record may be demoralizing for
>> you).
>>
>
> We would like people to re-evaluate the decision, but if that doesn't
> happen I think the PEP is still useful, since it provides a fair view of
> Roundup capabilities and discusses things that we will have to take into
> account if we proceed with the migration -- that's why we decided to go
> ahead and write the PEP.
>
>
>> > **Flexible UI.**  While Roundup UI might look dated, it is convenient
>> and flexible.
>>
>> I wholly disagree with this statement.
>>
>
>> The BPO roundup UI drives me nuts. every. single. time. I have to use
>> it.  It is not optimized for common workflows users actually need to
>> accomplish when using a bug tracker.  Two example usability issues (of
>> many): Users can't read the latest update to a bug of length because it is
>> hidden within the *middle* of the scrolling region, they must hunt for it.
>>
>
> This came up in the past, and two solutions have been proposed already:
> 1) keyboard shortcuts have been added in the issue page to quickly jump to
> the first/previous/next/last message and to the response box [0].  They
> support both mnemonic (f/p/n/l/r) and vim-style (h/k/j/l/i) combinations.
> You can find a summary table in the left sidebar of the issue page, under
> help -> keyboard shortcuts.
> 2) a patch to collapse the history by default (so that the last message
> was at the end of the page) was proposed and merged [1], but it was
> reverted after a few days because some devs wanted direct access to the
> history without having to do an extra click every time to expand it.
>
> After reading, the text box to add to the discussion is oddly located near
>> the *top* of the scrolling region so that a user cannot see context of a
>> bug discussion they are responding to as they type.
>>
>
> This has also been discussed and different people had different opinion.
> Some suggested to reverse the order of the messages so that the last
> message is at the top near the reply box (like Twitter does), but other
> said it's unnatural to read.  Some suggested to put the reply box at the
> bottom; however if the other fields are left at the top you would have to
> go back up to set them, and if they are moved down you won't easily see
> them at the top when you open an existing issue.  Another solution is
> duplicating the fields and response box at the top and bottom.
>

The two other modern bugtracker UIs I use on a regular basis do this by
having all such non-conversation metainfo in a persistent top and side bar
boxes such that it is always present.  Keeping the conversation and
metainfo changes listed in order (latest message at the bottom, metainfo
deltas interspersed in between messages all ordered/grouped by timestamp,
and reply text entry box below that.  These two are typically big-screen
engineering UIs (github being one of them), if mobile is desired i expect
these would effectively wind up as a multi-pane UI.  There's a third ticket
that I use for non-engineering stuff which does things in reverse order
with the text entry up top and messages in reverse chronological order
below that.  This reversal always annoys me; probably because I spend most
of my time in the others so it forces me to do headstands. I don't know if
there is a *right* answer between the two approaches, I just know what I
prefer. But the common theme is keeping new the update UI elements right
next to the most recent entries which is what BPO lacks today.

What I mean with *flexible* when I wrote the PEP, is that, unlike GitHub
> (where they decide), we can customize bpo however we want (as long as we
> agree on what we want -- we could even have per-user settings if we really
> want to :)
>

Definitely true in that sense.  Custom things, no matter where, are custom
code.  diverge from an upstream project in our own fork and maintenance and
updates become harder.  Author a pile of bots to automate tasks within a
standard API or UI (as is working great for our Github PR workflow) and the
equivalent maintenance burden falls on keeping the bots working.

I think I last heard discussion on the position of the response box in 2011
> (when shortcuts and history collapsing were discussed).  Maybe people
> didn't care enough about it so they didn't bother bringing it up or they
> didn't know it could be changed.  If 

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

2019-05-24 Thread Ezio Melotti
On Fri, May 24, 2019, 20:23 Gregory P. Smith  wrote:

> -cc: committers to avoid crossposting.
>

+1 (I wanted to include committers, since the announcement about PEP 581
was posted there too, but it's better to keep the discussion here)


> I have feedback for roundup as experienced on BPO that should be
> represented within PEP 595 if we are going to have a summary of "improving
> roundup for BPO" captured in a PEP (presumably already rejected given 581?
> But good to have documented regardless so _thank you_ for doing this
> writeup even though I realize our plan of record may be demoralizing for
> you).
>

We would like people to re-evaluate the decision, but if that doesn't
happen I think the PEP is still useful, since it provides a fair view of
Roundup capabilities and discusses things that we will have to take into
account if we proceed with the migration -- that's why we decided to go
ahead and write the PEP.


> > **Flexible UI.**  While Roundup UI might look dated, it is convenient
> and flexible.
>
> I wholly disagree with this statement.
>

> The BPO roundup UI drives me nuts. every. single. time. I have to use it.
> It is not optimized for common workflows users actually need to accomplish
> when using a bug tracker.  Two example usability issues (of many): Users
> can't read the latest update to a bug of length because it is hidden within
> the *middle* of the scrolling region, they must hunt for it.
>

This came up in the past, and two solutions have been proposed already:
1) keyboard shortcuts have been added in the issue page to quickly jump to
the first/previous/next/last message and to the response box [0].  They
support both mnemonic (f/p/n/l/r) and vim-style (h/k/j/l/i) combinations.
You can find a summary table in the left sidebar of the issue page, under
help -> keyboard shortcuts.
2) a patch to collapse the history by default (so that the last message was
at the end of the page) was proposed and merged [1], but it was reverted
after a few days because some devs wanted direct access to the history
without having to do an extra click every time to expand it.

After reading, the text box to add to the discussion is oddly located near
> the *top* of the scrolling region so that a user cannot see context of a
> bug discussion they are responding to as they type.
>

This has also been discussed and different people had different opinion.
Some suggested to reverse the order of the messages so that the last
message is at the top near the reply box (like Twitter does), but other
said it's unnatural to read.  Some suggested to put the reply box at the
bottom; however if the other fields are left at the top you would have to
go back up to set them, and if they are moved down you won't easily see
them at the top when you open an existing issue.  Another solution is
duplicating the fields and response box at the top and bottom.


What I mean with *flexible* when I wrote the PEP, is that, unlike GitHub
(where they decide), we can customize bpo however we want (as long as we
agree on what we want -- we could even have per-user settings if we really
want to :)


I think I last heard discussion on the position of the response box in 2011
(when shortcuts and history collapsing were discussed).  Maybe people
didn't care enough about it so they didn't bother bringing it up or they
didn't know it could be changed.  If people do speak up, we can change
bpo/Roundup.


  I file things like this under "User experience design is needed for the
> common workflows of all classes of users".
>
> Roundup needs a modern responsive web interface, not GET/POST request
> based interface seen on BPO.  As a result of that, roundup *feels* like
> is belongs in the Pre-2004 era interface wise by being web form and full
> page reload server for everything. A responsive modern "async javascript
> requests happen in the background of the UI" system that we all expect of
> any web UI is needed. Not just tweaking the existing thing to have a mobile
> friendly version of the web form. This includes persistent connections so
> that updates to an issue show up live as they happen instead of getting an
> error message "someone/something else has updated this issue since you
> started typing, the action you wanted to take such as submitting that
> comment or editing that field is now invalid and cannot be completed
> without a lot of manual work figuring out what happened, cut and pasting,
> and fixing things up on the you the users part".
>

This is a good point and I think it can be done now that Roundup has a REST
API.


> I'm not going to try proposing a PR to this PEP encapsulating that, I'll
> leave that up to anyone willing to wrangle such a PEP.  The list archive
> has it regardless now. :)
>

Thanks a lot for the feedback, I'll update the PEP once I get back to a PC
(using mobile now).

Best Regards,
Ezio Melotti

[0]:
https://bitbucket.org/python/tracker-cpython/commits/dbe3912f93895cd1c44fd353a0fd5db1b467a075
[1]:

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

2019-05-24 Thread Gregory P. Smith
-cc: committers to avoid crossposting.

I have feedback for roundup as experienced on BPO that should be
represented within PEP 595 if we are going to have a summary of "improving
roundup for BPO" captured in a PEP (presumably already rejected given 581?
But good to have documented regardless so _thank you_ for doing this
writeup even though I realize our plan of record may be demoralizing for
you).

> **Flexible UI.**  While Roundup UI might look dated, it is convenient and
flexible.

I wholly disagree with this statement.

The BPO roundup UI drives me nuts. every. single. time. I have to use it.
It is not optimized for common workflows users actually need to accomplish
when using a bug tracker.  Two example usability issues (of many): Users
can't read the latest update to a bug of length because it is hidden within
the *middle* of the scrolling region, they must hunt for it.  After
reading, the text box to add to the discussion is oddly located near the
*top* of the scrolling region so that a user cannot see context of a bug
discussion they are responding to as they type.  I file things like this
under "User experience design is needed for the common workflows of all
classes of users".

Roundup needs a modern responsive web interface, not GET/POST request based
interface seen on BPO.  As a result of that, roundup *feels* like is
belongs in the Pre-2004 era interface wise by being web form and full page
reload server for everything. A responsive modern "async javascript
requests happen in the background of the UI" system that we all expect of
any web UI is needed. Not just tweaking the existing thing to have a mobile
friendly version of the web form. This includes persistent connections so
that updates to an issue show up live as they happen instead of getting an
error message "someone/something else has updated this issue since you
started typing, the action you wanted to take such as submitting that
comment or editing that field is now invalid and cannot be completed
without a lot of manual work figuring out what happened, cut and pasting,
and fixing things up on the you the users part".

I'm not going to try proposing a PR to this PEP encapsulating that, I'll
leave that up to anyone willing to wrangle such a PEP.  The list archive
has it regardless now. :)

-Greg


On Thu, May 23, 2019 at 1:17 PM Ezio Melotti  wrote:

> Hello,
> Berker and I have been working on a PEP that suggests we keep using
> and improving bugs.python.org and Roundup instead of switching to
> GitHub Issues as proposed by PEP 581.
>
> The PEP covers:
> * What are the advantages of Roundup over GitHub issues;
> * What features are missing in Roundup and how can we add them;
> * Issues with PEP 581;
> * Issues with the migration plan proposed by PEP 588;
>
> The rendered version of PEP 595 is available at
> https://www.python.org/dev/peps/pep-0595/
>
> For reference, you can consult PEP 581 and 588 at
> https://www.python.org/dev/peps/pep-0581/ and
> https://www.python.org/dev/peps/pep-0588/
>
> The full text of the PEP is include below.  We are planning to update
> the PEP to include the feedback we receive and to update the status of
> features as we implement them (we also have a Google Summer of Code
> students working on it).
>
> Best Regards,
> Ezio Melotti
>
>
> 
> PEP: 595
> Title: Improving bugs.python.org
> Author: Ezio Melotti , Berker Peksag
> 
> Status: Draft
> Type: Process
> Content-Type: text/x-rst
> Created: 12-May-2019
>
>
> Abstract
> 
>
> This PEP proposes a list of improvements to make bugs.python.org
> more usable for contributors and core developers.  This PEP also
> discusses why remaining on Roundup should be preferred over
> switching to GitHub Issues, as proposed by :pep:`581`.
>
>
> Motivation
> ==
>
> On May 14th, 2019 :pep:`581` has been accepted [#]_ without much
> public discussion and without a clear consensus [#]_.  The PEP
> contains factual errors and doesn't address some of the
> issues that the migration to GitHub Issues might present.
>
> Given the scope of the migration, the amount of work required,
> and how it will negatively affect the workflow during the
> transition phase, this decision should be re-evaluated.
>
>
> Roundup advantages over GitHub Issues
> =
>
> This section discusses reasons why Roundup should be preferred
> over GitHub Issues and Roundup features that are not available
> on GitHub Issues.
>
> * **Roundup is the status quo.**  Roundup has been an integral
>   part of the CPython workflow for years.  It is a stable product
>   that has been tested and customized to adapt to our needs as the
>   workflow evolved.
>
>   It is possible to gradually improve it and avoid the disruption
>   that a switch to a different system would inevitabily bring to
>   the workflow.
>
> * **Open-source and Python powered.**  Roundup is an open-source
>   project and is written in Python.  By using it and supporting
>   it,