Hello Ted, I would actually be quite happy if we did rely on both JIRA and Discourse/forum for the different kinds of discussions as you were saying: sometimes I do believe that it is preferable to specialise more rather than add unwanted noise or inefficiency to a forced universal approach: different clear requirements requiring different solutions maybe a lot better than forcing a single compromise.
I think that although having two different places for discussions seems counterintuitive at first, as you said the adhoc and unstructured discussion of swift-dev or event swift-evolution at times does not really fit the JIRA model, but for bugs and proposals which are actually more self contained and structured work items the nature of JIRA fits a lot better and JIRA does offer a lot of integrations (with just a little bit of discipline keeping stories and GitHub PR's and commits too automatically linked is not hard at all). At work we do use JIRA for bugs/stories/spikes as well as all the discussion directly related to each of them and Confluence/HipChat/e-mail (although I think Discourse would fit an important niche for us). For bugs and stories you want to avoid noise or getting proposals lost, you want to be able to track their progress towards deliverable, etc... I am not here trying to sell you guys on JIRA ;), but I think that to use it effectively you would want the bug/stories filled with the right level of detail and with the directly connected discussion happening on the JIRA ticket as well (a JIRA ticket like a user story in agile is a conversation). Kind Regards, Goffredo Sent from my iPhone > On 31 Jan 2017, at 03:49, Ted kremenek via swift-evolution > <[email protected]> wrote: > > > >> On Jan 27, 2017, at 4:21 PM, Karl Wagner via swift-evolution >> <[email protected]> wrote: >> >> >>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution >>> <[email protected]> wrote: >>> >>> I'm surprised there is so little support for JIRA. Anyone think it's a bad >>> tool for the job? >>> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution >>> <[email protected]> wrote: >>>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution >>>> <[email protected]> wrote: >>>> I haven't yet seen a good answer to the question: who is going to put in >>>> the long-term commitment to host and maintain a replacement solution, >>>> moderate forums, make technical upgrades and backups, and perform all the >>>> other maintenance and administrative work it takes to properly run a >>>> system like Discourse, a web forum, or even a bug tracker. >>>> >>>> I will volunteer to be a moderator of the Swift forums. I have time >>>> available, and the core team surely has better things to do. >>>> >>>> Nevin >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> Personally, I’d prefer if we used GitHub Issues. I like keeping the current >> state of the project together with the known issues in it. It also has >> better formatting and actually supports some kind of syntax highlighting for >> Swift code. > > We did not go with GitHub Issues for our bug tracking for a few reasons (in > no particular order): > > (1) At the time Swift became open source, GitHub did not support arbitrary > attachments to issues, which seemed a non-starter since it is important to > allow users to be able to file meaningful bug reports with reproducible test > cases. This has since been resolved. > > (2) The locus of everything on GitHub is the repository. The Swift project > spans a bunch of repositories, and we felt it was not desirable to have > GitHub Issues, at least for the purposes of bug-tracking, on a per repository > level. Instead, we wanted a central place to file issues that had its own > affordances for organizing them. This is important for many reasons. First, > not all the logical "sub-components" have their own repositories, and it is > important to distinguish in the bug-tracker the differences between (say) > compiler and standard library bugs. We also found that users frequently do > not know what component — even if they are separate repositories in GitHub — > to file a bug report against, and often get it wrong. Having a central bug > database allows us to move things around. JIRA also provides a lot more > tools out of the box for managing issues at scale. > > Note that syncing with other bug tracking systems is not an issue with either > JIRA or GitHub Issues, since both provide nice web services APIs for querying > them. > > I completely agree that GitHub provides a nicer interface than JIRA, and > would be one less tool for us to use. Unfortunately, it doesn't match with > some important workflows we have in mind for bug tracking. It forces an > organization of issues that doesn't match with what the project needs. If > those problems did not exist, we'd almost certainly be using GitHub Issues > for issue tracking as that would more tightly match with the development > workflows of the rest of the project (e.g., pull requests). > > It's an interesting idea to use GitHub Issues or JIRA essentially as a forum > — but it feels a bit too structured. I pretty much share Goffredo's opinion > here on the value of a forum like Discourse versus using a tool like JIRA for > discussions. The discussions on swift-dev or swift-evolution often are just > discussion or even chatter — important chatter, but unstructured and ad hoc. > I can see something like GitHub Issues being a useful way for tracking more > official discussions, such as when a proposal is getting official discussed, > but I'm not certain if doing something different for those kinds of > discussions than what are done for the informal shop-and-idea-around > discussions on the mailing list would be worth it. > >> >> I just assumed that some of our requirements (e.g. syncing with Apple’s >> internal “radar” system) disqualified it. >> >> The reason why we don’t have topics every month about migrating our >> bug-tracking system is that JIRA (while perhaps not optimal) is at least >> passable. That’s more than you can say for the mailing lists, most of the >> time. >> >> - Karl >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
