Joel Madero-2 wrote > > Version 2, changed orientation and tried to take comments into > account. Let me know what you all think. > Hi. This is a very nice workflow, but I have some questions: - how you define "Bug prevent users from making professional quality work?" Interoperability issues are a big obstacle. If this package is supposed to read/write MSOffice files, then every new bug in this area should have high priority by default. I have reported two annoying: https://bugs.freedesktop.org/show_bug.cgi?id=47138 47138 and https://bugs.freedesktop.org/show_bug.cgi?id=49102 49102 . Are those "prevent users from making professional quality work" enough? Home users can live with a workaround, but it is impossible to expect that xx(x) users will do it xx times a day. Everyday. That is not "professional" (even worse - it is very "unprofessional" for those users migrated from MSO, where it just worked).
I'd change the workflow a little bit by putting the obvious things at the top: - feature requests aka wishlist - add target milestone if a feature is planned already - bugs reported against not supported branches - exclude those at reporting level by disabling old versions in select fields; but what to do when they appear anyway - mark them as INVALID at triaging? ask the reporter to check in new version? Any comments? - is it Most Frequently Reported - then just dupe it and now, if a bug is still there, triage it by the proposed workflow. - how you define most and many - I reported those two bugs on behalf of ~xx people - is my bug better than other reports? Should this be controlled by number of dupes? At what levels? Maybe enabling voting feature of Bugzilla would help here... - regressions - this is a major problem and I think it deserves its own place in the workflow. It is not a big problem for home users to switch the version back and forth. But when we are talking in terms of bigger deployment, when you have xx computers (and growing) it becomes a real blocker sometimes. What good are new and fixed versions for, where there is a regression which disqualifies the software for daily use? That is a big problem. - backtraces - not all people can do proper backtrace, especially on Windows, so maybe while triaging crash bugs one could ask for one a QA member? BTW: Having own dev build of LO 3.5.4.2 I can be QA contact for missing bt for all Windows crash bugs (except Base) on that branch. - permissions - seems like every user has canconfirm (Can confirm a bug) and editbugs (Can edit all aspects of any bug). Did you think about changing that, so one could not interfere with QA actions or vandalize the bug reports? Bugs triaged. But those are only b.f.o. bugs. Checking release info for 3.5.5.1 I can see such acronyms like bnc, i, rhbz and there are bugs reported on b.f.o. coming from aoo (where they may be fixed already). Not mentioning ubuntu, gentoo, opensuse and other bugtrackers. This is a very serious problem, because not all bugs are in one place. Any comments about that? Does the developers have their workflow in Bugzilla? I compared few commits (libreoffice/core libreoffice-3-5-5) with b.f.o reports: - 50603 - not assigned, UNCONFIRMED>RESOLVED FIXED - 43967 - assigned, UNCONFIRMED>NEW>RESOLVED FIXED>REOPENED>ASSIGNED>RESOLVED FIXED - 48601 - not assigned, UNCONFIRMED>NEW - 50988 - assigned, UNCONFIRMED>ASSIGNED>RESOLVED FIXED - 43249 - assigned, UNCONFIRMED>NEW>RESOLVED FIXED So, not bad but if there is more not assigned RESOLVED FIXED or NEW bugs with commits in the repo, then I see a problem here. QA should know what is happening with the bugs without the need to follow the comments. How does it look for xxxx commits? Also I see a lot of commits without bug report number in it. What is fixed then? I see it as another problem. I see you do not use QA field in Bugzilla. Why is that? Every component of a product can have its default QA specialist. Then developers responsible for a component quality can get a notice of new bugs instead of news about all of them. Also QA specialist assigned here could be responsible for bibisecting, bt delivery or verifying the bug. By the way - Browsing through dev/qa mailinglist I can see that you prefer those lists than bugs in Bugzilla. For instance - are those action items from ESC or QA meetings reported as bugs in Bugzilla? b.f.o is not used project wide or am I missing something? Do you VERIFY bugs? I see just 62 bugs as VERIFIED FIXED. I do not see such section in Getting Involved. Surely there are users willing to participate this way. I see you do not use flags and prefer Whiteboard. Why is that? Maybe a better idea than a MAB nightmare (IMHO meta bugs with >300 comments are useless) would be a release tracking flag, where QA would like to see a fix. Mozilla projects use them a lot for instance... Well, sorry for such a pack of off-topic questions, but I'd like to understand QA in this project better. Best regards. -- View this message in context: http://nabble.documentfoundation.org/Cleaning-bug-list-tp3988836p3991106.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
