Re: perlbug UX

Front page | perl.perl5.porters | Postings from March 2023

Thread Previous | Thread Next

From:

Dan Book

Date:

March 2, 2023 01:36

Subject:

Re: perlbug UX

Message ID:

CABMkAVU37kskmwTgyuv-msX2k9ism3dnrtayaRqJvKu1+VPz4g@mail.gmail.com

On Wed, Mar 1, 2023 at 3:14 PM Zefram via perl5-porters <
perl5-porters@perl.org> wrote:

> Dan Book wrote:
> >I don't entirely follow the question. The markup is on the non-user-edited
> >portion of the report, so that it is presented correctly.
>
> Ah, I think there was a misunderstanding a few messages upthread.
> My concern has been that something the user writes as plain text might
> get erroneously treated as markup.  Where you wrote about the markup
> being there to ensure correct rendering, I thought you were saying it
> was a solution to this problem that I'd raised.  But you're not saying
> that, you're not addressing the user-edited part at all; you're saying
> that the markup is to ensure that the non-user-edited portion renders
> correctly if interpreted as markup.  As I understand it, the problem
> that I thought there was with regard to the user-edited portion of the
> bug report absolutely does exist.
>

...


> The user experience of not knowing the intended language of a document
> I'm called upon to write has been confusing and worrying.  That's with me
> going in as a very experienced Perl user, very familiar with the former
> bug reporting process, and with the confidence to blow through the markup
> issue by asserting my own intended interpretation of the bug report.
> perlbug is quite likely to be the mode of a user's first interaction with
> the core developers -- I refer to it as an ambassadorial interface --
> so the friendliness of it is quite important.  Friendly treatment of an
> emailed bug report by a human can make up for some of the concern caused
> by the submission process, but it would be better to make the mechanism
> clear up front.
>
> I do judge other software projects by the nature of the bug reporting
> and patch submission processes, and by how the developers react to
> submissions.  I don't recall ever having been expected to write a bug
> report in anything other than plain text before.  The perlbug process
> is deficient, but it wouldn't take much to fix it.
>

I don't know what you propose to fix it. But I think you have demonstrated
a good understanding of what we've tried to do, with one exception: the
user does not need to know that the user-edited portion will be interpreted
as markdown, because they are the one who has chosen to paste it into a
markdown input and will understand that as a GitHub user, and markdown
formatting is intentionally designed to be readable as plaintext (aside
from the HTML syntax used for comments, which isn't too intrusive). Our
inserted markdown is simply to prevent the generated text from being
massively useless in such a case.

-Dan

Thread Previous | Thread Next