Obviously this is a bit simplistic, but you get the idea.

Make it extremely simple for end users to submit problematic documents, and let people who are familiar with the Bug Reporting system vette submissions from users, and modify the details as appropriate once the issue has been confirmed.

The sad fact is, if I was an average user, there is simply no way I would *ever* take the time to submit a document that had formatting problems, even if I could finally figure out *how* to do it.

This in my opinion would be the absolute easiest and best way to accumulate a boatload of documents to assist the devs in fixing file format compatibility issues.

(In reply to comment #0)
> Problem description: 
> 
> It is far, *far* too difficult/complicated for a simple user to submit
> Microsoft Office documents that exhibit compatibility issues.

I think we're all interested in how we can improve the experience for our users.

> This submission process should be very easy & accessible for users, and
> should *not* require anyone to log in or do anything else other than these
> two things.

Interesting. We've had a bit of discussion about whether one should have to login before submitting a bug report or feedback.

How would you address the problem of SPAM if we don't request a user account or at least an email address? We've had some issues with spam/trolling that could be exacerbated if we did not have at least some kind of speedbump in place.

> Once the document has been added to the submission report page to be
> uploaded, the user could then be prompted for additional (optional) details
> in succession (example to follow), all of which would initially be dependent
> on both the document type (doc/x, xls/x or ppt/x), and then the users
> responses to preceding responses.
>
> Example: [...]

One proposal for improving the BSA has been to ask the user several questions to help categorize the nature of a bug. Your proposed questions could be used to provide structured information about an attached document.

[Marking enhancement as NEW]

(In reply to comment #0)
> Say I have a Microsoft Office document (doc/x, xls/x, ppt/x) that exhibits
> compatibility issues.
> 
> I want to submit this document, along with a description of the problem(s),
> somewhere that it can be triaged (confirmed or not) by someone, and
> submitted to the right person to look at it more closely.

This is entirely my opinion as a user and layperson helper both here on bugzilla and more extensively in two user forums. As Qubit (QA) indicates "we're all interested in how we can improve the experience for our users" and I firmly support that sentiment. 

The main danger with the above is that it can result in an increase of reports like bug #67450. As Joel Madero (QA) points out in the related comments to that bug, it is fundamentally unhelpful to simply provide an example problematic file with a comment like "does not work" or similar. A report needs to be more specific if it is to have any chance of: (a) being understood / comprehended; (b) being reproduced; (c) being fixed. Developers usually fix single issues. A small report clearly outlining the steps required to reproduce a single problem is essentially a better report. If a small example file clearly showing the problem can be provided, so much so the better.

(In reply to comment #2)
>> This submission process should be very easy & accessible for users, and
>> should *not* require anyone to log in or do anything else other than these
>> two things.

> Interesting. We've had a bit of discussion about whether one should have to 
> login before submitting a bug report or feedback.

> How would you address the problem of SPAM

I think SPAM is one issue but IMO an even more important one is social responsibility. This is essential to the wellbeing of any community. Demanding that participants register for an account promotes this and is a fairly consistent approach across most sites where users can provide feedback and generally comment on issues.

(In reply to comment #3)
> (In reply to comment #0)
>> Say I have a Microsoft Office document (doc/x, xls/x, ppt/x) that exhibits
>> compatibility issues.
>> 
>> I want to submit this document, along with a description of the problem(s),
>> somewhere that it can be triaged (confirmed or not) by someone, and
>> submitted to the right person to look at it more closely.

> The main danger with the above is that it can result in an increase of
> reports like bug #67450.

Please just use 'bug 67450' (without the # sign) when referncing bugs so that the bug link is clicky... :)

As for your fear...

> As Joel Madero (QA) points out in the related comments to that bug,
> it is fundamentally unhelpful to simply provide an example problematic
> file with a comment like "does not work" or similar.

While I agree that the more precise a users initial description of the problem the better, the fact is, it only takes a minute or so to download a problematic document, open it in both Libreoffice and Microsoft Office (remember - this bug/feature request is *only* about Microsoft file format issues), and look for for obvious errors/problems.

> A report needs to be more specific if it is to have any chance of: (a) being
> understood / comprehended; (b) being reproduced; (c) being fixed.

Again, I agree that in most cases more detail is better, but I totally disagree that a developer cannot simply open a document in both programs, and spend a few minutes, and ascertain formatting problems/discrepancies... possibly even doing a much better job of doing so than the original reporter would ever be capable of.

A bare minimum from the user should just be something like 'open it in Libreoffice Writer 4.1.3 and Microsoft Word 2010 and compare pages 1 & 2'...

And these two pieces of information (the versions of each software) should obviously be part of the minimum mandatory info the user must provide.

> We've had a bit of discussion about whether one should have to 
> login before submitting a bug report or feedback.
> 
> How would you address the problem of SPAM

Explain in very clear language that in order for the user to submit a document for analysis, they must either log in with their bugzilla account, or provide an email address for confirmation purposes. Clearly explain that before their submission will be accepted, they will have to click a confirmation link in a confirmation email that will be automatically sent to them upon their initial submission. At least this would be the most obvious way off the top of my head. 

> I think SPAM is one issue but IMO an even more important one is social
> responsibility. This is essential to the wellbeing of any community.
> Demanding that participants register for an account promotes this and is a
> fairly consistent approach across most sites where users can provide
> feedback and generally comment on issues.

Again, I am much more concerned with Libreoffice having improved file format fidelity with Microsoft Office document formats than I am forcing someone to 'participate' in our community more than they wish to do. Encourage it, certainly, but don't *require* it...

I pretty much completely agree with Owen here. The lower we set the bar the more users will do what people tend to do which is "the least bit possible" - this is why I routinely puts bugs in NEEDINFO even if perhaps if I took a bit more time I could understand it - the reason being is that in the past this philosophy was taken and basically bug reports continued to get worse and worse. "Open this document and see the problem" when the problem is 10 pages long with text and other things going on - you say "it only takes a minutes" but let's say a bad report takes 3-5 minutes to triage (which isn't terrible) but a good report of the same problem takes 30 seconds - when we're talking about thousands of bugs, really it's the least a bug reporter can do is make it "as easy and clear as possible" so as not to disrespect QA's time - time is money, and mine is surely stretched thin right now. 

As for registering - we've already seen trolls even with registration and some people have been banned because of it. A much better solution is to get openID working so they don't have to have so many accounts - and this is currently being looked into. Again, the lower we set the bar the more work is puts on the shoulders of a very small team and that simply isn't fair. FLOSS is a community, if individuals don't want to be part of that community, there are plenty of other products out there that they can choose from or, they can sit patiently and wait for fixes (instead of giving a terrible report, getting irritated when the report goes into NEEDINFO and then every couple months saying things like "any progress" "why isn't this fixed yet" "can we expect a fix soon", either be a member of the community or don't, else, you're trying to take from the community and give nothing in return. 

In general though I don't see this being a problem at all - I very rarely see users angry about having to register and usually if I put a bug into NEEDINFO the user apologizes for lack of clarity and gives precise steps.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #0)
> >> Say I have a Microsoft Office document (doc/x, xls/x, ppt/x) that exhibits
> >> compatibility issues.
> >> 
> >> I want to submit this document, along with a description of the problem(s),
> >> somewhere that it can be triaged (confirmed or not) by someone, and
> >> submitted to the right person to look at it more closely.
> 
> > The main danger with the above is that it can result in an increase of
> > reports like bug #67450.
> 
> Please just use 'bug 67450' (without the # sign) when referncing bugs so
> that the bug link is clicky... :)
> 
> As for your fear...
> 
> > As Joel Madero (QA) points out in the related comments to that bug,
> > it is fundamentally unhelpful to simply provide an example problematic
> > file with a comment like "does not work" or similar.
> 
> While I agree that the more precise a users initial description of the
> problem the better, the fact is, it only takes a minute or so to download a
> problematic document, open it in both Libreoffice and Microsoft Office
> (remember - this bug/feature request is *only* about Microsoft file format
> issues), and look for for obvious errors/problems.
> 
> > A report needs to be more specific if it is to have any chance of: (a) being
> > understood / comprehended; (b) being reproduced; (c) being fixed.
> 
> Again, I agree that in most cases more detail is better, but I totally
> disagree that a developer cannot simply open a document in both programs,
> and spend a few minutes, and ascertain formatting problems/discrepancies...
> possibly even doing a much better job of doing so than the original reporter
> would ever be capable of.

If a bug requires me to open it in Microsoft Office then I can't solve the bug, quite literally. I don't have Microsoft Office anywhere running at my home. And there are quite some with me who only have/use LibreOffice.

> 
> A bare minimum from the user should just be something like 'open it in
> Libreoffice Writer 4.1.3 and Microsoft Word 2010 and compare pages 1 & 2'...
> 
> And these two pieces of information (the versions of each software) should
> obviously be part of the minimum mandatory info the user must provide.
> 
> > We've had a bit of discussion about whether one should have to 
> > login before submitting a bug report or feedback.
> > 
> > How would you address the problem of SPAM
> 
> Explain in very clear language that in order for the user to submit a
> document for analysis, they must either log in with their bugzilla account,
> or provide an email address for confirmation purposes. Clearly explain that
> before their submission will be accepted, they will have to click a
> confirmation link in a confirmation email that will be automatically sent to
> them upon their initial submission. At least this would be the most obvious
> way off the top of my head. 

That's why we are working towards openID. To lower this a bit. But I agree with JMadero in comment 5 about this. The easier it gets to enter a text the more bullies you attract.

> 
> > I think SPAM is one issue but IMO an even more important one is social
> > responsibility. This is essential to the wellbeing of any community.
> > Demanding that participants register for an account promotes this and is a
> > fairly consistent approach across most sites where users can provide
> > feedback and generally comment on issues.
> 
> Again, I am much more concerned with Libreoffice having improved file format
> fidelity with Microsoft Office document formats than I am forcing someone to
> 'participate' in our community more than they wish to do. Encourage it,
> certainly, but don't *require* it...

And when they file a bug that way, who is going to pick it up? We don't really have the manpower to keep up now, let alone when it increases with people who aren't interested in anything but filing their bug with the minimal requirements (and even try hard to go below that).

Let's just think about numbers also:

Let's say the average developer is probably making somewhere in the range of $25-$40/hr ( perhaps more, just throwing out a number). You say you disagree that a developer can't just open a bug and spend a few minutes trying to guess at what the user is trying to point us to. Let's say the few minutes is 5-10 minutes, we get 25 bug reports a day or so. So now we're at somewhere between $50-$100 a day wasted because users don't provide clear steps - this is really just unacceptable. Again, just to reiterate my previous point, you can either be a part of the community and share in the fruits of our mutual labor or you can sit on the side lines and "get what you get when you get it" - I honestly wouldn't be opposed to "kudos" points on our bug tracker so users who are clear and concise see benefits to being awesome. This is probably really unlikely to happen but if every user gave 1 hour a year or $1 dollar a year - well let's just say we'd be an awesome shape. Instead what we have is tens of millions of users and less than a couple thousand infrequent contributors and probably less than 500 frequent contributors (meaning in every team, devs, QA, localization, etc . . .) and some people suggesting that we ask less of our users and let them keep demanding so much of our time - seems like a counter productive strategy

IMHO this report doesn't provide anything clear that we can use going forward. My suggestion is mark as INVALID. 

If there are specific individual things that we want (such as openID) I suggest a bug report (enhancement) for the one single thing and that "bugzilla" or whatever is in the title of the bug. If this report is just saying 

1. No registration
my vote is no (but open to openID which should be its own report)

2. Allow users to submit documents without mandatory steps required
again my vote is no (I think requirements should be stricter actually)

3. Allow users to submit without info about their system
again, my vote is no (absolutely not, complete waste of QA's time, again I think the requirement should be stricter)

4. The "questions" by the system
As Qubit has mentioned - we're talking about a BSA version 2.0 - this is really Qubit and Rob's project - I am hardly in a position to demand anything of their time as I can't contribute much on the technical side. I do plan on diagramming out questions so that they can use what they want when we get to that project (which won't be until 2014 or later, this is valid but should be in its own bug with clear and precise language)

I guess because it's pretty unclear what exactly is being asked here other than the three things above (which actually is 4 reports in one I suspect), again my suggestion is marking as INVALID.

Created a new bug for item #4 - "see also" field

(In reply to comment #8)
> 
> 1. No registration
> my vote is no (but open to openID which should be its own report)

Bug 71651 - BUGZILLA: Add OpenID support

> 2. Allow users to submit documents without mandatory steps required
> again my vote is no (I think requirements should be stricter actually)
> 
> 3. Allow users to submit without info about their system
> again, my vote is no (absolutely not, complete waste of QA's time, again I
> think the requirement should be stricter)

So I think we have two choices here
1) We relax restrictions and instruct QA to triage reports more quickly, or
2) We keep/tighten restrictions, and give QA more time per report

Either one will discourage some subset of our userbase; I'm not sure which one is optimal.

(In reply to comment #10)
> (In reply to comment #8)
> > 
> > 1. No registration
> > my vote is no (but open to openID which should be its own report)
> 
> Bug 71651 - BUGZILLA: Add OpenID support

I am afraid that is a long-term plan

> 
> > 2. Allow users to submit documents without mandatory steps required
> > again my vote is no (I think requirements should be stricter actually)
> > 
> > 3. Allow users to submit without info about their system
> > again, my vote is no (absolutely not, complete waste of QA's time, again I
> > think the requirement should be stricter)
> 
> So I think we have two choices here
> 1) We relax restrictions and instruct QA to triage reports more quickly, or
> 2) We keep/tighten restrictions, and give QA more time per report
> 
> Either one will discourage some subset of our userbase; I'm not sure which
> one is optimal.

When we make the entering of bugreports easier we don't satisfy our user-base. Because the bugs they enter won't be replyed to, so they are still angry afterwards. So choice 1 will get you a angry userbase and angry community. The 2nd option gives you a angy userbase.
For me there is no choice as there is only 1 valid option as long as the QA-community isn't MUCH bigger.

Thanks for the thoughtful response.

Ok, I'm convinced that just letting someone upload a document with a comment 'it is broken, open it to see' would not be a good thing to do.

Also, the question of requiring them to register or not was just not a real part of this Feature Request, although it may have come across that way. If you want to require it, fine, but make it a simple part of the document submission process - ie, when they initially submit the document, by providing their email address (be sure to explain this clearly of course), they are actually registering with the system.

However (see below)...

(In reply to comment #5)
> I pretty much completely agree with Owen here. The lower we set the 
> bar the more users will do what people tend to do which is "the least
> bit possible"

So add some prompts for additional/minimal info as I suggested/described, ie:

'Where does the problem reside? choices: Header, Footer, Body (specific choices depending on the document type of course)

Then some few follow ups - ie:

'What page(s) exhibit(s) the problem?

Drill down with these kinds of simple prompts as much as you like, but I honestly don't see that much drilling down would be needed.

The main point I'm trying to make here is that requiring people (and please understand, by 'people' I mean 'ordinary' people - ie, NON-programmers, and people who may think a 'bug tracker' is someone trained in finding out where the ants are coming from) to go through the current Bug Tracker to report a bug for simple document formatting issues is raising the bar so high that I guarantee you at least an order of magnitude more people simply give up, than actually jump through all the hoops to successfully report a problem.

What this Feature Request is about is a new, simple and *separate* *interface* to the *existing* bug system, intended only for reporting compatibility issues with Microsoft Office file formats. And this same interface should be used when interacting with these specific bug types (ie, if a reporter is asked for more info, when they get the email and click the link, it takes them to the *simplified* interface as opposed to the main bug tracking system).

The whole idea is to keep things as simple as possible for people who are not technically inclined, but who interact with a lot of people who use Microsoft Documents.

> this is why I routinely puts bugs in NEEDINFO even if perhaps if I 
> took a bit more time I could understand it - the reason being is that
> in the past this philosophy was taken and basically bug reports
> continued to get worse and worse. "Open this document and see the
> problem" when the problem is 10 pages long with text and other things
> going on - you say "it only takes a minutes" but let's say a bad
> report takes 3-5 minutes to triage (which isn't terrible) but a good
> report of the same problem takes 30 seconds

That is precisely the problem this Feature Request is meant to resolve - getting good/better bug reports - but at the same time, to get *more* *of* *them*, by making it *easy* for people to make *good* bug reports. And again, I'm only talking about document formatting/compatibility issues.

> when we're talking about thousands of bugs, really it's the least a
> bug reporter can do is make it "as easy and clear as possible" so as
> not to disrespect QA's time - time is money, and mine is surely
> stretched thin right now.

The vast majority of bugs are extremely complex and have nothing (or little) to do with ODF<>MSO file formatting issues.

> As for registering - we've already seen trolls even with
> registration and some people have been banned because of it. A much
> better solution is to get openID working so they don't have to have
> so many accounts - and this is currently being looked into.

Yeah, and then you still have the problems of people who will never use OpenID, or who wouldn't know hot to use it if they wanted to.

> Again, the lower we set the bar the more work is puts on the
> shoulders of a very small team and that simply isn't fair.

Again - I'm talking about *lightening* the load. With an enhanced, simple reporting interface like what I'm talking about, you could get a lot more people who are interested in this particular aspect to do the initial triaging, thus *freeing* *up* developers time.

> FLOSS is a community, if individuals don't want to be part of that
> community, there are plenty of other products out there that they can
> choose from or, they can sit patiently and wait for fixes (instead of
> giving a terrible report, getting irritated when the report goes into
> NEEDINFO and then every couple months saying things like "any
> progress" "why isn't this fixed yet" "can we expect a fix soon",
> either be a member of the community or don't, else, you're trying to
> take from the community and give nothing in return.
> 
> In general though I don't see this being a problem at all - I very
> rarely see users angry about having to register and usually if I put
> a bug into NEEDINFO the user apologizes for lack of clarity and gives
> precise steps.

Yes - but for every user who actually knows how to work in bug trackers, or those who don't, but take the time to figure out how to register and actually report a bug, how many who eagerly tried to find out how to report a problem with one of the documents sent to them by someone else turned away in utter frustration and disgust at the convoluted, complicated process that is this bug tracker?

I would wager it is a very large multiple of the number of users who successfully report a bug to the satisfaction of the developers triaging them.

Anyway, this is just my point of view... and the reason I'm so interested in it is because our company recently went on a Microsoft Office buying binge because of the myriad of document compatibility problems with Microsoft's new XML file formats...

> What this Feature Request is about is a new, simple and *separate*
> *interface* to the *existing* bug system, intended only for reporting
> compatibility issues with Microsoft Office file formats. And this same
> interface should be used when interacting with these specific bug types (ie,
> if a reporter is asked for more info, when they get the email and click the
> link, it takes them to the *simplified* interface as opposed to the main bug
> tracking system).

That would mean rewriting a hughe part of what bugzilla does. As we are currently with 3 people (semi-)active working on the BSA, I don't see the manpower to create *another* gui. So in my opinion this isn't feasable.

I *really* hope a lot of people would quit talking what we should do and do it themselves, because I see a lot of ideas being discussed and all failing because nobody *does* it.

(In reply to comment #12)
> > As for registering - we've already seen trolls even with
> > registration and some people have been banned because of it. A much
> > better solution is to get openID working so they don't have to have
> > so many accounts - and this is currently being looked into.
> 
> Yeah, and then you still have the problems of people who will never use
> OpenID, or who wouldn't know hot to use it if they wanted to.

Anyone who has an account with
- Gmail
- Facebook
- Livejournal
- Launchpad
- (and others)...

..already has an OpenID account.

Think of it as "an email address that can function like an account". No account setup necessary, just log in and go.

(In reply to comment #11)
> When we make the entering of bugreports easier we don't satisfy our
> user-base. Because the bugs they enter won't be replyed to, so they are
> still angry afterwards. So choice 1 will get you a angry userbase and angry
> community. The 2nd option gives you a angy userbase.
> For me there is no choice as there is only 1 valid option as long as the
> QA-community isn't MUCH bigger.

You have got to be kidding me...

Having a complex system does not automatically equate to better bug reporting.

It all depends on *how* you make the process easier.

If, as I described, you have a simple form, that asks a few simple, but very targeted and specific questions that provide the level of detail you need to triage the bug report, then your comment falls flat on its face.

(In reply to comment #7)
> Let's just think about numbers also:
> 
> Let's say the average developer is probably making somewhere in the range of
> $25-$40/hr ( perhaps more, just throwing out a number). You say you disagree
> that a developer can't just open a bug and spend a few minutes trying to
> guess at what the user is trying to point us to.

Ahem...

I'm, envisioning such a system will attract a lot of people who are interested in improving this particular aspect of Libreoffice, and you will have an *army* of *volunterr* triagers (for these bugs) that not only are motivated to do a good job, but already have everything they need to do the work (ie, they have Office installed, etc)...

(In reply to comment #13)
>> What this Feature Request is about is a new, simple and *separate*
>> *interface* to the *existing* bug system, intended only for reporting
>> compatibility issues with Microsoft Office file formats. And this same
>> interface should be used when interacting with these specific bug types (ie,
>> if a reporter is asked for more info, when they get the email and click the
>> link, it takes them to the *simplified* interface as opposed to the main bug
>> tracking system).

> That would mean rewriting a huge part of what bugzilla does. As we are
> currently with 3 people (semi-)active working on the BSA, I don't see the
> manpower to create *another* gui. So in my opinion this isn't feasable.

Well, that is another thing entirely...

I was just imagining a web page that acquires the necessary bits and has hooks to auto-fill in the back-end fields in the existing system.

But maybe it is much more complicated than I was thinking...

> I *really* hope a lot of people would quit talking what we should do and do
> it themselves, because I see a lot of ideas being discussed and all failing
> because nobody *does* it.

If I was a programmer and had the ability, I would...

(In reply to comment #14)
> (In reply to comment #12)
> > > As for registering - we've already seen trolls even with
> > > registration and some people have been banned because of it. A much
> > > better solution is to get openID working so they don't have to have
> > > so many accounts - and this is currently being looked into.
> > 
> > Yeah, and then you still have the problems of people who will never use
> > OpenID, or who wouldn't know hot to use it if they wanted to.
> 
> Anyone who has an account with
> - Gmail
> - Facebook
> - Livejournal
> - Launchpad
> - (and others)...
> 
> ..already has an OpenID account.
> 
> Think of it as "an email address that can function like an account". No
> account setup necessary, just log in and go.

Oh, ok... didn't know I had one... ;)

Again this bug should be closed and the conversation moved to the mailing list IMHO

Closing this bug according to comment 19 after nearly 5 years. Maybe on the mailing list there is more interest for it. And it's not a bug LibreOffice can resolve directly in the program.