W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > July 2018

Re: Closing requirement issues on github?

From: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
Date: Mon, 2 Jul 2018 15:11:38 +0000
To: Antoine Isaac <aisaac@few.vu.nl>
CC: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <536624B0-424A-4CB4-9FE9-0C7ACDD7A6B2@csiro.au>
Yes, I think closing Issues with a quotes reason’s the way to go. Happy to keep open issues approved and mark them Approved. All the “from Google Doc” Issues not approved are talked with “requires discussion” as noted in the Google Doc.

Nicholas Car
Senior Experimental Scientist
CSIRO Land & Water
E nicholas.car@csiro.au<mailto:nicholas.car@csiro.au> M 0477 560 177<tel:0477%20560%20177> P 07 3833 5632
Dutton Park, QLD, Australia

On 1 Jul 2018, at 6:27 pm, Antoine Isaac <aisaac@few.vu.nl<mailto:aisaac@few.vu.nl>> wrote:

Hi Karen,

Yes that's right if they're closes they're still visible.
I must say that if some are the ones we agree were confusing then I won't oppose closing these. Still a bit of explanation on the closure would be useful - it's quite easy to do them when one close the issue, while trying to retrace later what happened is super hard.

What could be done:
- adding a label for the provenance, e.g. '6.1 spreadsheet section' (6.1 came from our old spreadsheet). Btw perhaps Nick should do this for all the requirements he created (he already marked them as coming from the Google Doc, but in comment not in label). Housekeeping labels are really powerful in github.
- adding a comment why it was closed.

Antoine

On 01/07/18 07:40, Karen Coyle wrote:
Sorry, Antoine, I should have checked.
There are all of the previous "6.1" requirements there that I put in
github for the f2f3. We talked about removing them because they are
confusing - that's the first one (209). Although "closed" gets them out
of our view, they don't really go away. I don't know how to mark those
because they aren't approved, they are kind of superseded.
The other one was one of the few of the new requirements that we have
discussed on github and I considered it (yep, unilaterally) done.
I'll restore both, and mark the one approved, but would greatly
appreciate some advice on clearing up the old ones. And at some point we
should consider the requirements "done".
kc
On 6/30/18 9:40 AM, Antoine Isaac wrote:
Hi,

Continuing on the discussion in the other thread - but trying to focus
on one aspect: closing github requirements.

I've seen that Karen closed two requirements issues
https://github.com/w3c/dxwg/issues/209

https://github.com/w3c/dxwg/issues/255


I'm not sure for the first (I miss the time to check) but I'm sure that
the second ("Requirement: There needs to be a property in the profile
where the rules for the descriptive content can be provided. This would
apply to the entire profile. [ID42] (5.42)") is one corresponds to a
requirement that we approved on the Google doc
https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/



As much as I don't like at this stage to create issue for every
requirement by default, I think we shouldn't make disappear the
requirements that happened to have been discussed and validated, after
we've decided to have the discussion on github because it was impossible
to have it on the Google doc.
This is what I've said to Nick, basically: when the Google doc effort is
finished, I agree the requirements should be on github (it's just that I
didn't feel we all have the bandwidth to pay attention to all of them on
github and the Google doc at once).

Perhaps once the discussion on github is finished and a requirment is
approved we can keep it open, and add a label like 'approved', instead
of making it disappear.

In any case, when we close issues we should always indicate the reason
why we're closing it in a comment or by assigning a label (for example
"won't fix"). I'm not a developer, but in my experience this is always
how I saw more github-experienced people than me were doing.

Cheers

Antoine



Received on Monday, 2 July 2018 15:12:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 25 March 2019 10:33:24 UTC