Would it be possible to automatically create JIRA tickets when a GitHub issue is being created? We could then mirror all comments the same way it's happening in https://issues.apache.org/jira/projects/MXNET/issues/MXNET-42 but make sure that the bot works in both ways. A comment on GitHub would be copied to JIRA and a JIRA comment to GitHub. I think this would be good as a first step to start integration.
-Marco On Wed, Mar 7, 2018 at 8:08 PM, Marco de Abreu <[email protected] > wrote: > I also see this as a big advantage in terms of transparency. I personally > will try to move away from any company internal issue trackers (except for > confidential cases) and instead work on Jira that is being managed by the > community. This allows everybody to see what is being worked on and gives > them the possibility to chime with ideas or suggestions. > > In my opinion, this obsoletes TT and SIM to a big extent. It's up to you > if you maintain multiple issue trackers or stick to one. If anybody has a > (non-confidential) issue that's related to my work on CI, I ask them to > create a GitHub issue instead of a company internal ticket - I invite > everybody to do the same. > > MXNet is an open source project and moving away from company internal > trackers towards community driven ones is the next logical step in my > opinion. At the moment, everybody is working on their own and it's hard to > see for external people (or even developer who are not part of the same > team) what we're actually working on. > > -Marco > > On Wed, Mar 7, 2018 at 7:48 PM, Naveen Swamy <[email protected]> wrote: > >> I am +1 for using JIRA. Managing bigger projects within MXNet on JIRA >> brings openness to the project. MXNet Users and the contributors also get >> a >> sense of where the project is heading. >> Bigger Tasks can be divided into sub-tasks which contributors can pick up >> small tasks based on their expertise on and contribute independently. >> >> On Wed, Mar 7, 2018 at 10:40 AM, Chris Olivier <[email protected]> >> wrote: >> >> > The vote was discussed on private@ before the vote on dev@, and the >> vote >> > went on for a very long time. There was ZERO resistance. No one >> "snuck" >> > it in or "slipped it by". >> > >> > This, hopefully, phases out both SIM and tt, which are both are being >> used >> > in ways that aren't what they're even designed for, IMO. Trouble >> tickets >> > are being used as a backlog for my team, which is insane. >> > >> > I've actually sent out a couple of mails on dev about contact me if you >> > don't have access to JIRA. If you would like to participate in the >> > direction of the project, please keep up with the dev email list. >> > >> > I gave you contributor permissions on JIRA, btw. >> > . >> > >> > >> > >> > On Wed, Mar 7, 2018 at 10:17 AM, Aaron Markham < >> [email protected]> >> > wrote: >> > >> > > I'm not quite sure if I have enough background on reasons for or >> against >> > > this to vote in the next round, but my two cents: I didn't see much >> > debate >> > > on why we need yet another tool for issues that we have to manually >> > > maintain...the vote kind of slid in there without many stakeholders >> > > realizing what they were being signed up for. I was thinking, sure, if >> > YOU >> > > want to make jira tickets, go right ahead. I have two internal >> ticketing >> > > systems to deal with already that assign tasks on MXNet, plus GitHub. >> > Jira >> > > would be four. Happy to make it work, but I'll need fifth tool to >> > aggregate >> > > communications and metrics between the other four tools! I'm only >> sort of >> > > joking. >> > > >> > > I saw Chris's response, and ok the public visibility part makes sense, >> > but >> > > does this phase out any other overhead? Does it integrate? Jira has >> > > integration options so maybe we can eliminate some overhead... Like >> > > something that hooks into the GitHub api and generates jira tickets on >> > the >> > > fly... I want to believe there's a plan that makes this all easier. >> > > >> > > What value I don't see is how we lower barriers to contribution and >> make >> > it >> > > more fluid for new users that could become contributors. What's the >> story >> > > and value proposition? >> > > >> > > Also, I don't see any docs on the website or on github on how to sign >> up >> > > for jira, or how to contribute according to this new requirement >> anywhere >> > > on the site. Myself and new contributors wouldn't know what the >> expected >> > > flow looks like because it's not really accessible. I now see the >> > > confluence wiki, but that's pretty much hidden from anyone browsing >> the >> > > site or github and looking to contribute. Why is this info on >> confluence >> > at >> > > all? Why not in the docs on github that are rendered to the website? >> Or >> > > conversely, why is some of the info on github and on the website, if >> it >> > is >> > > being maintained and current only on confluence? >> > > >> > > These are two separate issues really, but I think if you want buy-in, >> > this >> > > needs to be more transparent and obvious, and provide clear reasons >> and >> > > benefits to why you're asking for more overhead. >> > > >> > > Aaron >> > > >> > > On Mar 6, 2018 21:14, "Eric Xie" <[email protected]> wrote: >> > > >> > > > -1 >> > > > >> > > > JIRA is ancient and arcane. This adds unnecessary overhead. >> > > > >> > > > On 2018/03/03 06:11:12, CodingCat <[email protected]> wrote: >> > > > > This vote passes with 6 +1 votes (6 bindings) and no 0 or -1 >> votes. >> > > > > >> > > > > Binding +1: >> > > > > Chris Olivier >> > > > > Indhu Bharathi >> > > > > Suneel Marthi >> > > > > Yuan Tang >> > > > > Marco de Abreu >> > > > > Sebastian Schelter >> > > > > >> > > > > >> > > > > >> > > > > Vote thread: >> > > > > https://lists.apache.org/[email protected]:lte= >> > > > 1M:tracking%20code%20changes%20with%20JIRA%20by%20associatin >> > > > g%20pull%20requests >> > > > > >> > > > > I will continue with pushing the content to wiki and take it into >> > > > practice >> > > > > >> > > > >> > > >> > >> > >
