Hello koha-devel, I'm doing a checking of our bugzilla usage. I've added some pages on the wiki about submitting a patch, and have some questions/propositions. Please give me your opinion about them. The propositions that won't be agreed by all (unanimity) will be discussed in a later IRC meeting. Here they are, in random order. • what's the difference between master and Rel_3_8 versions ? I feel "master" should not be used for bugs, only for ENH, and, when a patch is submitted for an ENH, it should be attached to "next planned version" (ie : Rel_3_8 those days) • The priority is used to set "patch sent". This is a problem as we completly loose Priority field usage. A solution would be to have a patch status "patch sent" added, have the patch status always visible, and keep priority for what it's supposed to be, the priority. Patch status could then be "--" (patch not sent), "needs signoff", "does not apply"... as we have today. • QA contact : could we do a better use of this field ? I know Ian & QA team are working/thinking to this question, so it's here just for reminder. • Signed-off & passed QA = The signature and the QA process could be in any order: if a patch does not meet our QA rules, there's no need to test it if the QA team sees it. So maybe we have a field for "QA status" (-- / passed QA / failed) and the patch status for sign-off (-- / signed off / does not apply) • For instance, I don't know how we could keep track of the "patch submitter" ? do we want/need ? I throw an open question here. • bug status : it's NEW/ASSIGNED/RESOLVED and it's not really correctly used. Many bugs stay "new" = as of today, 12 bugs have a patch for version Rel_3_8 and are still marked "new". They should be "assigned". I propose to enforce the use of the "ASSIGNED". This question is connected to the question of the use of the default assignee i've asked a few weeks ago. • Components : I proposed to clean them a while ago. Now I have concrete & detailled propositions. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap I've checked all entries with less than 30 bugs open, and propose something for each of them. The global idea is to have component entries close from modules we have in Koha. ∘ About, importedbugs, = no bugs, drop those entries. ∘ Authentication = 19 bugs, move them to "architecture, Internals and plumbing" ∘ Browser compatibility = 10 bugs, move them to "Architecture internals and plumbing" or "templates" ∘ bugs.koha-community.org = 2 bugs, move them to "websites, mailing lists,..." ∘ contribs.koha-community.org = 1 bug, move it to "websites, mailing lists,..." ∘ Developer documentation = 5 bugs, move them to "Architecture, internals and plumbing" ∘ Documentation = 11 bugs, keep them here, interesting for Nicole & doc writers ∘ Holidays = 2 bugs, move them to "Tools" ∘ Installation and upgrade = merge "command line" and "web-based" (20 and 24 repectively) ∘ Label printing = 27 bugs, move them to "Tools" ∘ MARC authority and MARC bibliographic (26 and 27 repectively) = we could merge them, not sure, i'm not proposing that, your opinion/thoughts about that ? ∘ MARC bibliographic staging/import = 14 bugs, move them to tools ∘ Self-checkout = 4, move them to "circulation" ∘ SIP2 = 18, move them to "circulation" or "Architecture, plumbing" ∘ Test suite = only 3, but keep them as we want to improve test coverage, it's to encourage ppl ! ∘ Transaction logs = 5, move them to "Tools" ∘ translate.koha-community.org = 2, move them to "Websites, Mailing lists,..." ∘ Z39.50, SRU, OpenSearch = 14, move them to searching • The "hardware" field is useless. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=rep_platform&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap 12 are reported "MacIntosh", and not related to Mac specifically, others are PC/All/Other. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?) • The 'OS' field is useless. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=op_sys&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap ∘ 5 bugs are "windows", and 3 are "others", it does not seem they are relevant. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?) • Version field : there are many, only a few are used : http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap Could we hide all versions that are unsupported and have no bug opened now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08