Research Increasing Support Forum Post Character Limit

[pmac]

See this post in the contributor forums for context. The tl;dr is that pastebin.m.o is slated for retirement and without another pastebin recommendation the support forums may need to support larger posts to accommodate the info copied from about:support.

My initial thoughts are that we should keep the support forum character limit and find an alternate recommendation for a pastebin. Our database is already huge and increasing the amount of data stored and served by those views doesn't seem like a good direction for us. I might even prefer that we stand up a support pastebin with auto-expiry of posts rather than recommend this content live in kitsune itself. But, I'm willing to be convinced otherwise.

All suggestions are welcome.

/cc @jgmize @metadave @jpetto @glogiotatidis

[safwanrahman]

I think we can ad the needed value to the System Details page or add a download button in the System details page so the contributor can download the full about:support data.

[bookshelfdave]

I'd recommend not putting any more load on the DB. At it's current size (db.m4.4xlarge) it's still getting hit with spikes >= 80% CPU.

[safwanrahman]

The feature I proposed does not need aditional DB space, we already about:support data, but currently we show limited number of information, so the contributor needs to see more information.

[pmac]

@safwanrahman oh yeah. Like on the question linked to from that form post I see a whole lot of info when I click the "more system details" link. Is that not everything? Also how are we capturing that? I'm reading code now, but I'm now confused again about what they're asking for? For what are people using pastebin.m.o if not system details from about:support?

[safwanrahman]

@pmac I believe there is not everything. Like Web Content Processes and many more.

[pmac]

Yeah, those things have come along since the last time this code was touched I'm sure. I wonder if we're saving it but not displaying...

[philipp-sumo]

improving the stuff that's showing up under "more system details" would certainly be very well received - maybe we can open a separate issue about it...

but since only a minority of question owners is opting to provide those details at the time of submitting their question, we certainly also need a way to ask for that data after the fact when the thread is already ongoing.

[pmac]

I believe there is not everything. Like Web Content Processes and many more.

I pinged you on slack with an example (private in case the info is sensitive) but I do see maxContentProcesses and currentContentProcesses in the data.

improving the stuff that's showing up under "more system details" would certainly be very well received - maybe we can open a separate issue about it...

+1 let's do that

but since only a minority of question owners is opting to provide those details at the time of submitting their question, we certainly also need a way to ask for that data after the fact when the thread is already ongoing.

It looks to me like an easy(ish) way around this is to provide the question asker a button on the page allowing them to attach this info if it's not already there. Would that be sufficient combined with improved access to said data? We just have to be privacy conscious with this so that we don't expose any data the asker doesn't want exposed.

[pmac]

Oh. @safwanrahman you can see what data SUMO collects by going through the AAQ flow for Fx desktop, getting to the form, clicking the "share data" button, and then the "see the data" link that shows up. There's a whole lot of good stuff in there, but I'm guessing some things we would definitely not want to expose to the anonymous viewers of the question. Perhaps we could provide a full JSON download only to verified SUMO contributors?

[Dinodog]

Could we (or do we already) purge the about:support data collected after some time? I think a 45 or 90 day time period would do.

[pmac]

@Dinodog I don't believe we do, but it seems likely that we could. Do you want to do this for privacy reasons or just database size considerations?

[pmac]

I've talked a bit more with @safwanrahman and we've come to an agreement for this:

1. It seems my fears of adding load to the database for the troubleshooting data are unfounded since we already have mechanisms for storing this and are storing it for a lot of questions. So I don't think improving this feature will add significant load.
2. We should be able to accommodate the request from the original forum post by @philipp-sumo by doing 2 things:
   • Adding access to the full raw JSON dump in the database for contributors.
   • Adding the ability for question askers to attach these data to their question after it's posted if they opted not to do so during the initial ask. Either this capability exists and I haven't found it, or I think we could add it reasonably easily.

If we had the above features would that solve the initial question? Are there other data we'd like to have askers give us in question comments that they can't currently? If so perhaps we also need a good pastebin recommendation.

I also wonder if it'd be useful if a question asker could update the troubleshooting metadata during the process of a question discussion?

[pmac]

I was playing with the AAQ feature, and I think the thing I mentioned above is already supposed to work. If you ask a question you can then edit your question later. The edit question form includes the button to add support data to your question. However, that button for me seems to be broken. Does it work for anyone here? Is this just a bug? If so I think all we need to do is:

1. Fix the ability of the question asker to attach support data when editing their question
2. Add the ability for contributors to get to the full JSON content of the attached support data

Is that right?

[philipp-sumo]

perhaps people posting with other browsers where the troubleshooting api doesn't work is also a case to keep in mind.

[pmac]

I wouldn't think people could get to about:support information from any other browser. Or do you mean that we sometimes need to help people with browsers they don't directly have access to? In which case we'll probably need an external suggestion anyway.

[philipp-sumo]

sometimes people post with crashing/page loading issues that make it difficult for them to use firefox while they're on sumo. but yes, in those instances getting to about:support might not be possible either...

[rtanglao]

see also https://bugzilla.mozilla.org/show_bug.cgi?id=1480438#c22

tl;dr from mike hoye in slack:

In short, we are probably going to end up with our own, very-short-timeout pastebin in-house, and add something like "mach gist" for amything needing longer-term storage.

but i gather the above solutions won't be in time for september 1st

[pmac]

Thanks Roland. I have been following that bug, and it seems that if we do get another pastebin it will only allow posts to live for an hour or so, which I don't think would work well for our needs. The recommended tool for long-lived pastes is gist (https://gist.github.com/), which is great, but might pose a significant barrier in that one needs an account to use it. If we're happy enough with Gist then I think we can just recommend that when someone needs to post a long bit of info that is outside of the about:support data.