bug report warning area is too much

[Brynn]

Hi Friends,
This isn't really about Inkscape. It's about the excessive warnings below the message box, when you are composing a new bug report. I've made a screenshot to show what I see.

It's so long, that I could not capture it all in one shot. I scrolled so that you can see the bottom edge of the message box, at the top of the screenshot. And at the bottom of the screenshot, there are really 3 or 4 more lines of that triangle warning symbol below, that you can't see.

I think this gives the impression that the Inkscape project has lost its patience with its users, and implies a rift.

I've put a rectangle around the area that I think should be sufficient to keep. I think making it red would not be too much, if that would be possible. But that long string of symbols just gives the wrong impression, in my opinion.

Thanks for listening :-)

PS - In providing support for Inkscape users every day, I know how tiring it gets to keep having to ask for the info. But if we've lost our patience to do that in a nice, pleasant way, perhaps it's time to take a break? Thanks again :-)

[Mc (mc...)]

Yeah, it seems to much, I reduced it to what you showed.
But TBH, the LP interface, by putting it after the writing area (and not as a template prefilled into the writing area, for instance), does not make it stand out

[Brynn (brynn4inks-deactivatedaccount)]

Thanks Mc !

I agree that having it at the top would be better.

It might be worth investigating that further, except from what I understand, we may be migrating bugs over to Gitlab Issues in the foreseeable future.

Maybe better to investigate ways to do that at gitlab?

Or maybe....I thought it was an issue which was put to the Vectors team, to come up with some kind of flowchart type of form (I think it's supposed to go on the website) for reporting bugs, which would help newbies to be able to make bug reports on their own. But I can't seem to find an Issue for it, at the moment.

But anyway, maybe that should be the focus?

[Patrick Storz (ede123)]

Hi Brynn,

I'm a bit late to the party but as the one who set the "bloated" version let me explain how it came to life.

First of all you already noted that giving support for Inkscape can be tiring. Now I guess with your background in the forums you are used to people not giving any information at all and slowly getting there - that's one of the jobs we have the forums for after all.
Here in the bugtracker however I feel we *need* to be more efficient. A bug report lacking information is a "dead" bug report that is unlikely to ever be looked at. That is not only frustrating to the reporter (they certainly wasted their time) but also makes bug triaging much more complicated for everybody else (wasting a lot more resources down the road).
As we don't have enough resources for bug triaging right now (let alone fixing) the least we can do is to strive for reports that are as good as possible from the start, to keep the workload per bug as small as possible.

Now
- after asking the zillionth time for Inkscape version, OS, and steps
  to reproduce I decided we probably need to improve something
- the possibilities Launchpad gives us are limited, so I had to do
  with what little we get for the time being.
- in my first iteration there was only text
  (no warning symbols, "IMPORTANT" or whatever)
  Result: only slight increase in "good" reports
- therefore in my second iteration I added one "IMPORTANT"
  and the warning symbols (a little less than the cut down version
  you highlighted and Mc set now)
  Result: People started to *begin* noting the information
  I guess roughly half of the reports were "good"
- It was obvious the quality of reports improved, but I still had
  the feeling many people did not really read it at all (as I doubt
  anybody would omit information on purpose if they had read it).
  So I thought about *why* people still missed it and I concluded
  it had to be the Launchpad layout that kept drawing people's
  attention directly to the "Submit bug report" button
- therefore in my third iteration I bloated the informational text
  vertically to push the button down and out of view on purpose.
  Also I "experimented" with a new passage of text explaining
  *why* that information is so important to make people understand
  our motives - nobody likes being told what to do without explanation.
  Result: In my subjective perception after this change - although I fully
  admit it was "a bit much" thre majority of bug reports started to
  include at least Inkscape version and OS. Often also sample files.
  Steps to reproduce was still problematic, but that's nothing we
  can solve overnight I guess...

So in conclusion I still think bloating this text makes sense.
If others feel it's "too much" I'd prefer if we tried to optimize the wording and appearance to sound less "impatient" while still conveying the message.

One thing I thought about was to put a link to a page that has more information. I found [1], unfortunately it turns out that page does not have a lot of easily understandable information on how to write a "good bug report" but directly dives into the technical details of using gdb (and therefore is completely unusable IM...

[Patrick Storz (ede123)]

P.S. Just to give you and impression, when I say "guide on how to write good bug report" I mean something along the lines of [1] (there's so much truth to this document!). Written for non-programmers in a way to make them understand how a developer actually works with the provided information and what they can do (and shouldn't do!) in order to help and increase their chances of a fix.

Obviously this is a long document and people are often impatient, too (yes, as a developer I get the exact same feeling when I get a "bad" bug report), so I'm not sure something like this would help either...

[1] https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

[Brynn (brynn4inks-deactivatedaccount)]

We do already have this page, on the website, about writing bug reports: https://inkscape.org/en/contribute/report-bugs/. I helped with writing that, mostly just changing language so that less technically-oriented users could use and understand it better. I'm sure it could use further improvements.

When you click on Help menu > Report a bug, that's the page that opens. And from there, the user has a link to Launchpad. At the moment, I can think of maybe putting bullet points at the top of that page, including the main things which are needed in a bug report....and then below the bullet points, the link to LP, and below that put everything else.

That might make it more of a streamlined process, for people who take that route to reporting. Because I suspect users are taking the link in the first sentence to LP, and not reading the page. (I could write up a proposed edit for that page, if you think it would help. I would make the bullet list at the top, and only put the link below it. And then flesh out a bit more below that.)

When people first post in a forum about a possible bug, we always, without fail, instruct them what needs to be included in the bug report. I sometimes link to that page, but usually I just type the instructions in the forum message. I can't speak for everyone, but personally, if I've urged someone to report a bug, and they do, I double-check to make sure they included everything.

When people first post in social media....well, that's where the request came from, for a flowchart type of document (I'm assuming it would be something like a flowchart, or numbered steps, or something very structured), which would allow newbies to figure out whether what they have found is a bug or not, and how to report it. Otherwise, I'm not sure if there is any good route for social media users to get to, or find instructions about, reporting a bug.

Although that request was brought to the first meeting of the Vectors team, it doesn't look like it was ever documented in an Issue, in the Vectors team gitlab account. Personally, I'm not sure if that would be the best solution. But on the other hand, creating the Issue would make a place for it to be discussed further.

What would you think about something like that?

So let's see, we have a route for reporting a bug directly from inside Inkscape (Help menu), and we have a route from forums. We don't really have a route (that I know of) for social media users to learn how and to write bug reports. But we have a proposal for the flowchart type of webpage, which potentially could serve everyone.

And the other route which is not covered is someone who does not see the Help menu item, who already knows about the LP bug tracker, and just browses here independantly (not via link). If we could put a link on the new bug report form to the website page, that would cover this route to reporting a bug, as well as if someone is coming from social media.

Would that work?

I can't say anything new or different about the 15 lines worth of warning symbols and explanation points, than I said before. I just think there must be a more friendly and inviting way to get users involved in r...

[Patrick Storz (ede123)]

> We do already have this page, on the website, about writing bug reports

That's the one I linked an as you noted, too, it certainly could use some improvements. I'm afraid it does not serve its purpose particularly well right now (it's too long and not structured enough with the important information being too well "hidden" like I think is unfortunately the case for a lot of content on the website).

I think this page could/should serve as a first point of contact for all channels of communication (after an overhaul) and could also be linked from the bug tracker then.

> flowchart type of document

This is the first I hear of it and I have no idea what this is about (probably not the scope of this bug though either...). I'm not sure if such a format could work - if it's very well done maybe, but if it's only pretty but does not convey content we're where we started.

What I imagine could work for that page:
- a short and concise introduction (e.g. bulleted list) what information
  needs to be in each bug report
- a slightly longer explanation (not more than a paragraph) how that
  information is used by triagers and developers (i.e. why important?)
- link to launchpad
- new chapter on the lifecycle of a bug that explains the stages each bug
  goes through, what triagers / developers do and how the reporter can
  (and should!) help with the process.
  This can use some of the existing content, some from the essay I linked
  and maybe some newly created content.
- At one stage debugging/gdb will come up. I'd not include this on the
  page but link to [1] instead (which needs some updates, too, but
  that's even farther off the topic).

Either way none of this will actually help with the actual issue this bug is about: The content we enter into the description field on Launchpad.
We need to make sure people read it (we can be creative! I tried...) otherwise all the content we can come up is in vain.

I'm sure once we move to GitLab we'll have better options, until then we need something functional (instead of big plans for the future), so I invite you to say something new about "the 15 lines worth of warning symbols and explanation points" after all ;-)

Improving this short term seems more important then to get it absolutely right sometime in the future, and many lines of warning symbols might seem intrusive but at least achieved their goal...

[1] https://inkscape.org/develop/debugging/

[Brynn (brynn4inks-deactivatedaccount)]

 > That's the one I linked an as you noted

Oh, I'm sorry, I missed that.

 > I'm sure once we move to GitLab we'll have better options, until then we need something functional (instead of big plans for the future), so I invite you to say something new about "the 15 lines worth of warning symbols and explanation points" after all ;-)

What future? I can have a proposal for the improvements you suggested for that page, later tonight! I would not be able to write about the "life cycle of the bug report" because I don't really know it. But I do have edit access to that page, and I can write a proposed edit right away.

I don't have anything "new" to say about the 15 lines worth of symbols. I think it gives the impression that developers and/or bug managers have lost their patience with users who are reporting bugs (at best) and (at worst) are grumpy. I would fear that a first time bug reporter might instantly become a last time bug reporter.

**Is there really no way to put such a note at the top of the report form??**

(It seems awfully short-sighted of LP not to provide some way to customize the form. It seems like they would expect each user project might have different instructions, when they built this site.)

Would it be possible to make the current 9 line warning red? If that's possible, I could live with that.

I wonder if it would be possible to put the needed text actually inside the description field? Just make it part of everyone's message? Of course it doesn't need to be part of everyone's message, but at least bug reporters would see it that way....I mean, see it before they finish writing their message.

Another softer way to present it might be to replace the other (~6) extra lines (which were removed), but just use blank line spaces, rather than put the warning symbol on each line. That would put a big space above and below, and therefore bring more attention to it. What would you think about that?

OH! Ooorrr..... Here's a compromise I could live with, right now, whether the webpage is edited or not. Replace the triangle/exclamation point symbol with a smiley face, and I'll be a very happy camper :-) (well, I mean a tiny graphic, not "colon dash parenthesis" ....I assume that triangle symbol is made with unicode, and I'm sure I've seen a smiley face one somewhere)

Or it would not have to be smiley face....what about a thumb-up? Or alternating between smiley face and thumb-up might grab attention?? Or even just check-marks would be fine!

Ok, this would be the ideal for me. A few blank line spaces before and after (no symbols). Then change the current triangle symbols to checkmarks. But I could also live with checkmarks on all the lines.

(I'll start editing the page anyway. Because until I looked the other day, I didn't realize the Help menu was linking to that page. So it definitely needs some attention! :-) )

[Patrick Storz (ede123)]

> What future? I can have a proposal for the improvements
> you suggested for that page, later tonight!

That's great news! I'd be happy to review. The "future" part was mostly pertaining to anything GitLab might offer (in future...) and maybe also a tiny part skepticism (as I know I mostly fail to actually contribute to the website content after formulating my initial idea).

> Is there really no way to put such a note at the top of the report form??

To the best of my knowledge, no (and I feel like I checked everywhere at least trice, however the logic behind Launchpad navigation still eludes me).

> Would it be possible to make the current 9 line warning red?

Styling is not possible, only plain text.

> I wonder if it would be possible to put the
> needed text actually inside the description field?

No option for bug templates either...

> just use blank line spaces

Tried that, too: Empty lines are removed from the message (I also tried to fill them with spaces and non-breaking spaces - no luck either). That's how I ended up with the warning symbols ;-)

> Replace the triangle/exclamation point symbol with a smiley face [...]

Good idea! That's what I mean when I say we can be creative!
If we can make it welcoming and informative at the same time *and* achieve our goal of drawing enough attention that would be great!

I'll try something later. If you have further suggestions let me know.

> I'll start editing the page anyway.

Perfect, I'll make sure to include the link in the informative text.

[Brynn (brynn4inks-deactivatedaccount)]

Ah, well unfortunately, I ran into a problem with making a proposed edit to the page. There have been a lot of changes to how the site works, since the last time I did much work there.

I've asked for help on the mailing list (Docs list) but no answer yet. Oh, but I just thought of a different route. Maybe I can get it going shortly.

I'll keep you posted.

[Brynn (brynn4inks-deactivatedaccount)]

Yes, I'm in business now. Should have a rough draft soon!

[Brynn (brynn4inks-deactivatedaccount)]

Just had a thought. On other websites, regarding entirely different kinds of software, I've seen setups where the (usually a) forum provides a bulletted list of the required info, which the user fills out for their unique problem or situation.

I wonder if we could somehow find a way to do that? Like for example, what if we put such a list on the page I'm editing? They could copy and paste into the description here at LP, and then edit with their own unique info.

I've never been on the management end of such a setup, so I don't know how it goes in usual practice. Maybe it turns out not to be helpful at all, I don't know. But I've found it super convenient as a user.

Still, just a thought :-)

[Brynn (brynn4inks-deactivatedaccount)]

I'm sorry this is taking so long. I keep getting interrupted. With any luck, I'll have a draft later today.

[Brynn (brynn4inks-deactivatedaccount)]

Ok, here's an extremely rough draft: https://inkscape.org/en/report-bugs-2-edit/

The current page is here, for comparison: https://inkscape.org/en/contribute/report-bugs/

Yes, the footnotes are crazy, and to be honest, college was so long ago, I can't remember all the rules. In some places, I used asterisks, in another place, I put a traditional superscript "1". I guess the asterisks are not really footnotes per se. They need to be within the same h2 heading section, rather than the bottom of the page. (Can't think what the word for that is, BS class of '81)

You'll also see some color highlighted text, which are a couple of questions I have about whether to include that particular text at all. Just match the color of the text with the color of my question.

I have no doubt that others can improve on not just the footnotes, but the text and language.

Originally, I wanted to just have short bullet lists at top, with explanations and descriptions below. But I just fear that some newbies will be in such a hurry that they won't see important tips, such as discussing the problem with other users, before making the report. And other things.

So instead, I used bold text for the main steps. So people in a hurry can just see the bold, and get there fast. Hopefully new users will take the time to read in between the bold.

But I'm certainly not married to this, and fully expect it needs more work -- which I completely welcome!

At some point, I want to post about this change to the Docs mailing list, so that others on the website team can review it (who might not have seen this bug report). I'm not sure if it's ready for that yet? But if you think so, let me know, and I'll make the post.

I've left out the part you suggested about the life cycle of a bug, which I agree needs to be on a separate page (although linked would probably be good). And I also left out the GDB part, which I hardly understand at all. But you had suggested that it doesn't really fit on this page, so I left it out.

I'm thinking that the section "Other bug reporter responsibilities" maybe should go under "Make the bug report..." section? Easy to do, if you agree. Maybe "Why is this important" section should also go below "Make the bug report"??

Do you have edit permissions on the website? If so, you're welcome to hack away at it yourself. Or else just tell me what changes you want. Or would you prefer to switch to email or something else?

[Patrick Storz (ede123)]

Hi Brynn, great work!

I just gave it a quick read and while pretty much different from what I most likely would've tried, I think it's very helpful for the intended audience (likely more helpful as I'd probably write from a developer-biased point of view making wrong assumptions after all...)

Some things I noticed:
* The "footnotes" are confusing and distract the reader.
  Either it's important (then it should be included in the text itself)
  or it's minor and should be left out

  We might use "details" sections to include in-depth explanations
  that are unnecessary to understand how to file a report but might
  be important for certain users (I added an example at the bottom of the
  page, unfortunately the summary part does not work on the website)
* I'd agree the purple part reads a bit strange.
  Let's cut it (or rewrite - I'll see if I can come up with something)
* I already have a suggestion for the green part
  (will add it on the page)
* The second/third sections are already great conceptually, but I think
  we need to improve the language a bit to make it more clear what we expect
  (obviously keeping it short, though, which is a bit of a challenge)

[Patrick Storz (ede123)]

I've updated some parts, let me know what you think and let's iterate (here, per mail, whatever you prefer...)

[Brynn (brynn4inks-deactivatedaccount)]

I don't have any real complaints about your changes or suggestions. They all are great improvements (I know I'm not very good at the "PC" type of language - I tend to be overly wordy).

For resetting the prefs before making the bug report. This is actually the first time I've heard that. I've never done it myself, except for once on request of a developer who was answering the report. Should that really be a requirement before reporting? Or should users wait for a developer to request it?

That is mentioned in an faq item already, although I can't remember which one. It's not an item by itself though. I've only ever heard it suggested as a troubleshooting step.

Regarding the not-really-footnotes, which I used asterisks for. I've got to look at the source code and figure out how you made a <br> within the bullet item. If I could make a double-space within the bullet item, that would solve the problem about what to do with the asterisked comments! Also, it seems you managed a double-space between the bullets, which I much prefer as well.

Yes, I'll lose the pink comment. It was just carried over from the original, because for some reason, I thought whoever wrote it originally, was fond of the quip. But it really doesn't fit with this new sort of paradigm for that page.

Regarding replacing the green comment with what you said you "pirated" from that article. Did you pirate it such that it needs to be quoted, credited, and linked? Or is it more like paraphrased?

I'm not sure about the part about developers being "dull". Could we say "distracted"? Or...."not paying attention"? Or something else? "Dull" sounds more like "boring", which doesn't really fit.

Also, should we really say "years". That could really be discouraging! I'd probably say "weeks" but I could live with "months". Well, not unless we re-word it to mean the time it takes to fix a bug, rather than to answer a report.

Ok, I'll make some changes according to your comments, and I'll let you know as soon as it's published.

[Brynn (brynn4inks-deactivatedaccount)]

I've made all the changes we mentioned, but I can't seem to publish the page. I click the blue Publish button, the blue line goes across the top of the page, but nothing else changes. I know Martin had posted a message on the dev list about some unusual activity on the website, and that he had disabled email until the problem gets sorted out. So maybe that's affecting publishing? Hhm, now getting Bad Gateway in a black popup message. Guess I'll just leave it unpublished

[Brynn (brynn4inks-deactivatedaccount)]

(It just now published.)

[Brynn (brynn4inks-deactivatedaccount)]

I don't know why the link in the last paragraph "this page" doesn't show up. Possibly it's related to the current problem on the website (possible attack recently)?

[Patrick Storz (ede123)]

> For resetting the prefs before making the bug report.
> This is actually the first time I've heard that.

Well, it's a common step to rule out that the issue is simply caused by some setting that might have been accidentally changed (happens quite often actually) or caused by some illegal entries in the preferences.xml.

It's not useful in all cases (and specifying *when* it is would be too complicated I think), but it's a fairly quick check and can save a lot of time in determining the cause of an issue.

> That is mentioned in an faq item already

We recommend it at some point in A Windows-specific FAQ I think but "resetting preferences" seems like a very common troubleshooting step and seeing as we do not offer it via the UI I think a separate FAQ entry is justified either way

> it seems you managed a double-space between the bullets

I probably just "hacked" the source (as I can not bear the rich-text editor). Maybe try "Shift + Return" (I think this also allows for double spaces but I might be wrong)

> Regarding replacing the green comment with what you said you "pirated"
> from that article. Did you pirate it such that it needs to be quoted,
> credited, and linked? Or is it more like paraphrased?

I liked the message of the original article and worked from there, i.e. it's not a verbatim copy. (I actually put a link to the article but even if we were to remove it we'd be safe).

> I'm not sure about the part about developers being "dull".

Yeah, I searched for a "nice" phrasing here that was not too strong but also captures the feeling that sometimes develops on the reporter's side when the developers seems to be too "stupid" to understand the problem (or seem not to care or appear to be of different opinion, etc.). Often this leads to people starting arguing about it which does not help either party and therefore should be avoided. "Distracted" doesn't really capture it, in German I'd have used "begriffsstutzig" [1] but I'm not sure the translation into English works well ("dim" might capture it best but I'm not sure if that's readily understood by non-native speakers...)

[1] https://www.dict.cc/?s=begriffsstutzig

> Also, should we really say "years". That could really be discouraging!

I think yes! It certainly *is* discouraging but it's the truth. If we say weeks (or even months) and after a year there is still no notable activity I think that's even worse, as being realistic from the start (maybe we can point out that "help is always welcome as we aim to reduce response times" or something...). From a reporter's point of view I think the time it needs to answer a bug is irrelevant: The ultimate goal for a reporter is to get their problem fixed, so that's the timeframe that matters, even if the bug would be properly triaged after an hour. The phrase "get to your report" means just that for me, but if you think it's unclear feel free to rephrase (although tbh I've also seen bugs unanswered after years, so either interpretation is actually correct)

[Brynn (brynn4inks-deactivatedaccount)]

I don't have a problem with making a new FAQ item. You (or someone) would need to give me the gist of it though, since I'm not positive what you mean. You're talking about renaming preferences.xml, and restarting Inkscape, right? Or is there more?

Yes, I looked at the source and figured out how you made the better spacing. I applied what you had done (with line spacing) in the first section, to the whole thing. I think it helps with readability.

Instead of dull/dim, how about "slow"? "....developers might seem a bit slow...." ?? Or maybe "less timely"?? Or even "too busy"??

To non-developers, the phrase "before somebody gets to your report" could easily be interpretted as how long before someone reads it. Almost always a report is assigned a status and/or importance within a few weeks, it seems. But if they think it might not even be read within a year, that would not be a good impression to give.

Regarding "years", how about "....it might take a while before the bug is fixed...." ? Or instead of "fixed", maybe "resolved" ?? Or instead of "bug" it should probably say "issue" so as to cover feature requests as well. "....it might take a while before the issue is resolved...."

So putting altogether:

"....it might take a while before your issue is resolved, though (anywhere between hours and years). In any case try to be as kind and as helpful as possible (even at times when developers might seem a bit scarce from your perspective ;-)...."

Just thought of "scarce" ??

[Patrick Storz (ede123)]

> You're talking about renaming preferences.xml, and restarting Inkscape,
> right? Or is there more?

That's basically it.
The one question we need to answer is "where do I find "preferences.xml", though (and that's different for every OS - maybe even for different packages on the same OS).

> Instead of dull/dim, how about "slow"?

I could live with "slow", but from your suggestions I get a feeling we'd imply a different meaning ;-)
With this half-sentence I really did not want to say anything about the actual "speed" with which bugs were addressed. Instead I wanted to point out that at times developers might appear to ask "stupid" or "redundant" questions - seemingly intending to annoy or anger the reporter. While that's probably seldom true (although not impossible - sometimes developers really don't get the point the reporter is trying to make) this is when reporters need to be patient with developers (for their own sake) in the sense of staying positive, not in the sense of giving them more time.

> To non-developers, the phrase "before somebody gets to your report"
> could easily be interpretted as how long before someone reads it.

And it would have been interpreted correctly (sometimes there is no answer at all...)

> Almost always a report is assigned a status and/or importance within
> a few weeks

That's unfortunately far from the current status. Some bugs are "confirmed" but close to none are actually "triaged" (i.e. assigned an importance).

> But if they think it might not even be read within a year,
> that would not be a good impression to give.

So you'd rather we lied to reporters? The said truth is that there might not be an answer within a year (and instead of giving the false impression that there probably be one just to make it "look" good I'd rather tell the truth and acknowledge our bug team is understaffed.

> "....it might take a while before the issue is resolved...."

This implies it will be resolved eventually (which is yet another promise I'd prefer not to give as I'm sure we we won't be able to keep it in most cases).

We're slowly arriving at the point where I hope it get's clear why I wrote "it might take a while before somebody gets to your report" in the first place:
There's a chance somebody will look at a report and there's a chance a bug will be fixed. Both are well below 100% and combined there are more reports that stay unresolved than can be properly addressed.
Now we can write a lot on the bug reporting page - I'd prefer if we stayed true to ourselves and the people taking the time to file a report.

After all openly communicating that hands are needed might gain us contributors. I myself started contributing after my bug reports went unnoticed (or at least unresolved) for years and I first got pissed and then realized stepping up and putting in some work myself was the (only) way to get my issues adressed sooner.

[Brynn (brynn4inks-deactivatedaccount)]

>> You're talking about renaming preferences.xml, and restarting Inkscape,
>> right? Or is there more?

>That's basically it.
>The one question we need to answer is "where do I find "preferences.xml", though (and that's >different for every OS - maybe even for different packages on the same OS).

We (in forums) always direct them to Inkscape Preferences > System > User Preferences. That always gives the correct path, doesn't it?

For the new FAQ item, is this ok for the main question "How to reset user preferences" ?

For all the rest of your last comments, it's all good. You have experience as a developer that I don't have. So I really have to defer to you about that.

The only point that I would continue to want to change, is the potentially "years" before anyone looks at your report. Isn't there any way to soften that? Something like "of course we try, but sometimes we just don't have enough developers to handle all the requests" or something like that?

I'm going to go ahead and clean up some of our "notes to self", and except for the paragraph with the "years" part, I'll get it ready to submit to the mailing list, for one last review, before putting it live.

Is that ok with you? I mean the part about posting to the mailing list for a fuller review?

[Brynn (brynn4inks-deactivatedaccount)]

Ok, I made the new FAQ item and linked it to the new page.

Somehow I had missed the part at the very bottom of the page about making screenshots or videos or whatever. The link to Licecap was already on the page, so I kept that. But I'm not sure if you really want info about how to make a screenshot and stuff.

I actually wrote a little tutorial about making screenshots for newbies on my forum. But I know most of the website team does not want a lot of 3rd party links on the website. Although now that I think of it, the Licecap link is a 3rd party link already, haha.

Well anyway, here's that tutorial. If you think it's helpful, we could link to that as well: https://forum.inkscapecommunity.com/index.php?action=articles;sa=view;article=12 I know that Screencast-O-Matic is an easy-to-use video app for newbies. So that might be a good one to suggest.

But that would make 3 3rd party links. Maybe it would be better to let folks find their own resources, and not even have a footnote??

[Patrick Storz (ede123)]

> We (in forums) always direct them to Inkscape Preferences > System > User
> Preferences. That always gives the correct path, doesn't it?

Yes, that sound's like a good approach for most cases. In the unlikely case Inkscape does not start at all due to broken preferences (not very common) we can consider adding these bits later.

> The only point that I would continue to want to change, is the potentially
> "years" before anyone looks at your report. Isn't there any way to soften
> that?

Well, I already considered it "softened" enough (I guess most developers and other people familiar with how software development works will actually see the winking eye I implied), but your concerns show how differently people interpret these thing. Feel free to soften it if you know a way, but the "hard truth" is that a couple of reports always go unanswered for a lot of different reasons (lack of time, nobody able to reproduce, report just too hard to understand, so exotic set-up nobody can even try to confirm, etc.).

[Patrick Storz (ede123)]

> Is that ok with you?
> I mean the part about posting to the mailing list for a fuller review?

Totally! The more eyes the better. I'm sure people will have more ideas on how to make it easier to understand and find potential ambiguities.

> Somehow I had missed the part at the very bottom of the page about
> making screenshots or videos or whatever.

It was only a (technical) idea how to add additional information to the page that is initially hidden (thereby not distracting on the first read) but can e expanded by users if required. (I mentioned it quite early as an idea on how to avoid some of the footnotes). The content was mostly non-sensical and certainly nothing I felt we'd *need* to include on the page.

As for the third-party tool and suggestions on how to make screenshots / etc.:
Personally I'd have gotten rid of them!
There are so many tools out there and everybody prefers different ways of creating these kinds of media, so there's only limited gain in highlighting a few. More importantly I feel the Inkscape website should not be a general "guide on how to use a computer". We should be able to assume certain things as "common knowledge" as explaining every detail of every step we might require users to take will inevitably convolute every page to the level where it becomes unusable to everyone.

[Brynn (brynn4inks-deactivatedaccount)]

Ok, I'm fine with losing the footnote completely. If someone is reporting a bug, they probably already know how to make a screenshot.

Why don't we go ahead and post to the mailing list, with "years" intact. If someone else catches it, we can make a change. Otherwise, we'll just leave it as is?

I assume you're much busier than I am, so I'll be glad to make the post. But if you'd rather make it, I'm fine with that as well. (I've removed the footnote, so it's ready now (except for pasting the contents over to the actual page, and removing the red "do not delete" comment at the top).)

[Patrick Storz (ede123)]

I'll be busy till next week but yes, please feel free to go ahead!

[Brynn (brynn4inks-deactivatedaccount)]

Ok, posted :-)

[Brynn (brynn4inks-deactivatedaccount)]

There's some discussion on the mailing list about how the page should be (or could be) formatted.

We had started with a Normal Template (which is my preference). Then Martin suggested using the Side Panel template, which I misunderstood, and changed to the Table of Contents Template.

I'm not sure how the side panel would be an improvement, but maybe I just don't see whatever Martin is thinking. (side panel example is Sponsors page)

Anyway, if you have some time, we could use some input from you as well.

Thanks :-)

[Brynn (brynn4inks-deactivatedaccount)]

The Docs list, btw.

[Brynn (brynn4inks-deactivatedaccount)]

I'll forward you the whole thread, in case you aren't subscribed to that list.

[Brynn (brynn4inks-deactivatedaccount)]

Ok, the new page is published!

But just in case it's not enough, to solve the problem of people not reporting version, os, and etc., I'm wondering if you still want to try something like the smiley face icon or wingding, or whatever it is, that makes those warning triangles. Or maybe a checkmark icon?

[Patrick Storz (ede123)]

I added the link to the bug reporting guidelines.

Let's see if the smileys are more effective at drawing attention without angering reporters (or wether they distract them so much they forget what they wanted to report ;) ).

If you have additional ideas let me know.

[Brynn (brynn4inks-deactivatedaccount)]

I very much like the look and the tenor of the new "warning" message, which now comes across better as a reminder!

Hopefully being a little bit friendlier won't make it less effective.

Thanks for working with me on this. I know you're very busy.

There's one last matter that I can follow up on. I just need to run it by you for accuracy. During our discussion, you had mentioned a few other changes.

One was a new page for the website - the life of a bug or bug report. That's not something I could write, but I agree that it would be informative, and possibly help to encourage more reporting. (Well, I could probably write it with help.)

And the other (without re-reading this whole page) I think was an update to the Bug Management, or maybe it was Debugging page? Or maybe both? These are those links for convenience

https://inkscape.org/en/develop/bug-management/
https://inkscape.org/en/develop/debugging/

I can't make those updates, not even with help. But I could make sure all of these are recorded as Issues in the website's gitlab account, where website concerns are handled. That way we don't forget that these things need doing.

Do I remember the right page or pages which need updating?

All best!

[Patrick Storz (ede123)]

> One was a new page for the website - the life of a bug or bug report.

That was an early idea for the "Report Bugs" page. The idea was to explain to the average user how the bug team / developers work with their reports in hopes of making users more aware of the work happening after they filed their report, the amount of effort involved, and how they can help to improve the turnaround.

With the new bug page we went a different way and I think we achieved a very good result, so this page is not needed anymore. The interested user might refer to the link to Simon Tatham's page, which has the general idea.

> And the other I think was an update to the Bug Management,
> or maybe it was Debugging page?

The gist was that gdb commands do not belong on the "Report Bugs" page and the "Debugging" page might need an overhaul instead (e.g. there are no instructions for Windows at this time). It's not extremely urgent, as I'd consider using gdb only for advanced users anyway (i.e. small group of people) and we could make it work so far, but in certain scenarios (mainly while trying to determine the cause of the more complicated bugs) it might be nice to have instructions around that the average user can understand and work with.

[Brynn (brynn4inks-deactivatedaccount)]

Oh ok, I had not realized you meant the life cycle of a bug as a replacement for the Report Bugs page. So I'll forget about that.

Yes, the removal of the GDB info is why Maren contacted me about this in the first place. And I explained that you thought one of the pages needed updating to include that info. And she wanted me to make sure an Issue was created about that, so it isn't forgotten.

So that's what I'll do. I'll make an issue saying that the Debugging page needs an overhaul, and specifically needs to include the GDB info for Windows (because it doesn't exist anywhere now).

Thanks again for your help. If you don't have any other comments, we can close this report now (I don't have the right kind of access).