JIRA labels (no worries)


(Jordan Rose) #1

Hey, Brian. Re: your comment about labels <https://bugs.swift.org/browse/SR-1613?focusedCommentId=14864&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14864>:

By the way, I'm curious for your thoughts on the swift-3.0 label, which I introduced in https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160516/000662.html. I've seen you "curate" labels in the past, so I hope I didn't step on your toes by creating one. I tagged this task as "swift-3.0" because it's a sub-task of SR-710 <https://bugs.swift.org/browse/SR-710>, which is also marked "swift-3.0" – we want to be able to generate tests lists before shipping corelibs-xctest.

I knocked the "swift-3.0” label off because this was the first time I’d seen it in a non-corelibs issue, and because I wasn’t sure we had committed to doing this particular subtask in Swift 3—or rather, I wasn’t sure the SourceKit team had committed to doing this in Swift 3. I feel weird having release labels assigned by people working in other parts of the project because it feels like forcing the SourceKit engineers to fix it. I know that (a) wasn’t your intention, and (b) is probably accurate—as in, if this alternate solution hadn’t come up someone would have had to do something—but I reacted to it anyway and removed the label.

I do think now it was a bit of a knee-jerk reaction, so I apologize. As you noted, I’ve generally been the one adding labels, and removing or standardizing some of the ad hoc ones input by issue reporters; in this particular case that led to an instinct to remove a label I hadn’t seen rather than thinking about it. Certainly active contributors should be able to introduce new labels they find useful.

SR-1613 is resolved, so it’s kind of a moot point now, but do feel free to add useful labels in the future. If it matches one I’ve seen before I might standardize it, but I won’t remove them. Or if I do I’ll at least comment about it. :slight_smile:

Jordan

P.S. “swift-3.0” also doesn’t match my naming convention for labels, which is UpperCamelCase, but given that I didn’t write it down anywhere or tell anybody I can hardly complain!


(Brian Gesiak) #2

Hey Jordan,

Thanks for the email! Very good point -- and I definitely felt weird
assigning "Swift 3" labels to tasks, considering it's not up to me to
decide what goes into Swift 3 or not. Still, I think it's helpful to see,
at a glance, what are the time-sensitive tasks for a given project.
Ideally, the tag would be named something like
"ItdBeSwellToGetThisDoneInTimeForSwift3IMHO" :slight_smile: Seriously, though, ideas
for better label names would be very welcome!

And I appreciate the naming convention! I was wondering myself, but ended
up going with the casing used by the Swift 3.0 release branches.

Anyway, thanks for the clarification!! Very much appreciated. And no need
to apologize for removing the label, I didn't take it personally. :slight_smile:

- Brian Gesiak

···

On Thu, May 26, 2016 at 11:13 PM, Jordan Rose <jordan_rose@apple.com> wrote:

Hey, Brian. Re: your comment about labels
<https://bugs.swift.org/browse/SR-1613?focusedCommentId=14864&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14864>
:

By the way, I'm curious for your thoughts on the swift-3.0 label, which I
introduced in
https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160516/000662.html.
I've seen you "curate" labels in the past, so I hope I didn't step on your
toes by creating one. I tagged this task as "swift-3.0" because it's a
sub-task of SR-710 <https://bugs.swift.org/browse/SR-710>, which is also
marked "swift-3.0" – we want to be able to generate tests lists before
shipping corelibs-xctest.

I knocked the "swift-3.0” label off because this was the first time I’d
seen it in a non-corelibs issue, and because I wasn’t sure we had committed
to doing this *particular* subtask in Swift 3—or rather, I wasn’t sure
the *SourceKit* team had committed to doing this in Swift 3. I feel weird
having release labels assigned by people working in other parts of the
project because it feels like forcing the SourceKit engineers to fix it. I
know that (a) wasn’t your intention, and (b) is probably accurate—as in, if
this alternate solution hadn’t come up *someone* would have had to do
something—but I reacted to it anyway and removed the label.

I do think now it was a bit of a knee-jerk reaction, so I apologize. As
you noted, I’ve generally been the one adding labels, and removing or
standardizing some of the ad hoc ones input by issue reporters; in this
particular case that led to an instinct to remove a label I hadn’t seen
rather than thinking about it. Certainly active contributors should be able
to introduce new labels they find useful.

SR-1613 is resolved, so it’s kind of a moot point now, but do feel free to
add useful labels in the future. If it matches one I’ve seen before I might
standardize it, but I won’t remove them. Or if I do I’ll at least comment
about it. :slight_smile:

Jordan

P.S. “swift-3.0” also doesn’t match my naming convention for labels, which
is UpperCamelCase, but given that I didn’t write it down anywhere or tell
anybody I can hardly complain!


(Greg Parker) #3

Inside Apple we often use the term "nominated" for "I think this should go into release X, but it's not my call". Here that suggests labels like "Swift3Nomination".

···

On May 27, 2016, at 10:05 AM, Brian Gesiak via swift-dev <swift-dev@swift.org> wrote:

Hey Jordan,

Thanks for the email! Very good point -- and I definitely felt weird assigning "Swift 3" labels to tasks, considering it's not up to me to decide what goes into Swift 3 or not. Still, I think it's helpful to see, at a glance, what are the time-sensitive tasks for a given project. Ideally, the tag would be named something like "ItdBeSwellToGetThisDoneInTimeForSwift3IMHO" :slight_smile: Seriously, though, ideas for better label names would be very welcome!

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler