OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Thoughts on using JIRA for ODF 1.4 and beyond

    Posted 10-02-2020 19:10
    Greetings! As I construct complete change-tracked versions from ODF 1.2 to ODF 1.3, I've had a chance to really experience our usage of JIRA. Large chunks of it. Some suggestions/comments as we move forward to ODF 1.4: Summary Field: Let's not put section numbers, etc., which are likely to change. Use <element> name or element@attribute if you need to talk about a particular attribute for an element. That will make tracking a lot easier. Personally I don't find the fix version versus affects version distinction all the helpful. Can we agree to always use just one or the other? If we need to target a prior version for correction, let's just create a new issue and list it as affects that version, for example. I think if we regularize that practice, that will help as well in terms of not missing anything. Make every JIRA issue an issue for one numbered section only. If the problem is spread across several sections, let's create several JIRA issues for it. Not one JIRA issue that spans several sections. More to the editors than anyone but pointing to email comments imposing another step of indirection in working on the issue. Each distinct issue should have a separate JIRA issue and be confined to the *description* section. The proposal section remains *blank* until the TC agrees on a resolution and that resolution is recorded in the proposal field, along with the date the TC agreed upon the solution. Any significant opposition to this process going forward for ODF 1.4? (I persist in thinking software tracking systems are ill-adapted to standards work but it's the tool we have at the moment.) Hope everyone is at the start of a great weekend! Patrick -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Attachment: signature.asc Description: OpenPGP digital signature


  • 2.  Re: [office] Thoughts on using JIRA for ODF 1.4 and beyond

    Posted 10-06-2020 08:59
    hi Patrick, some thoughts below... On 02.10.20 21:10, Patrick Durusau wrote: Greetings! As I construct complete change-tracked versions from ODF 1.2 to ODF 1.3, I've had a chance to really experience our usage of JIRA. Large chunks of it. Some suggestions/comments as we move forward to ODF 1.4: Summary Field: Let's not put section numbers, etc., which are likely to change. Use <element> name or element@attribute if you need to talk about a particular attribute for an element. That will make tracking a lot easier. i agree that summary must contain the element or attribute name, but i think it doesn't hurt if in addition to that it contains some section number. Personally I don't find the fix version versus affects version distinction all the helpful. Can we agree to always use just one or the other? If we need to target a prior version for correction, let's just create a new issue and list it as affects that version, for example. I think if we regularize that practice, that will help as well in terms of not missing anything. we need to track some target version somewhere, so we are able to distinguish important issues that should go into the next ODF version from "wishlist" issues that have a lower priority. in the past we have used "Fix Version" field for this purpose, and this has the convenient consequence that this field now contains useful data in most issues (except those in state NEW). i think that "Affects version" is bit less useful, it's useful for defects in the specification, but i don't see the point of it for new features.... but when it *is* useful, it will naturally have a different value from the "Fix Version" as described previously. i agree that if we want to target a fix of some defect for multiple ODF versions, e.g. for errata, we should clone the issue and assign different "Fix Version" to each, so that we can track the progress per version. Make every JIRA issue an issue for one numbered section only. If the problem is spread across several sections, let's create several JIRA issues for it. Not one JIRA issue that spans several sections. i don't necessarily agree with this; in some cases the same problem needs to be fixed in multiple places, and if there are multiple issues it means it's easier to apply some of the issue resolutions but not others, and it also makes it harder to coordinate writing N proposals that are consistent with each other. More to the editors than anyone but pointing to email comments imposing another step of indirection in working on the issue. Each distinct issue should have a separate JIRA issue and be confined to the *description* section. i don't have an opinion on this, but note that JIRA's rich text formatting could mangle the email formatting. we can try it and see how it works, maybe add {noformat} tags around the pasted text... The proposal section remains *blank* until the TC agrees on a resolution and that resolution is recorded in the proposal field, along with the date the TC agreed upon the solution. agree, except that we should use the *resolution* field for this, not the *proposal* field. my preferred way would be to edit the proposal field until there is a rough consensus, then vote on the issue, then write into the resolution field "resolved as proposed" with a link to the meeting minutes. Any significant opposition to this process going forward for ODF 1.4? (I persist in thinking software tracking systems are ill-adapted to standards work but it's the tool we have at the moment.) good to hear your ideas about workflow improvements; agree that JIRA has a few pesky issues here... Hope everyone is at the start of a great weekend! Patrick regards, michael -- Michael Stahl Senior Software-Entwickler LibreOffice CIB software GmbH GeschÃftsstelle Hamburg Flachsland 10 22083 Hamburg T +49 (40) / 28 48 42 -296 F +49 (40) / 28 48 42 -100 Michael.Stahl@cib.de www.cib.de Sitz: MÃnchen Registergericht MÃnchen, HRB 123286 GeschÃftsfÃhrer: Dipl.-Ing. Ulrich Brandner