[swift-corelibs-dev] JIRA labels (no worries)

[Brian Gesiak]

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" :) 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. :)

- Brian Gesiak


On Thu, May 26, 2016 at 11:13 PM, Jordan Rose <jordan_rose at 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. :-)
>
> 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160527/75a0397e/attachment.html>