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 <aaron.s.mark...@gmail.com> 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" <j...@apache.org> wrote: > > > -1 > > > > JIRA is ancient and arcane. This adds unnecessary overhead. > > > > On 2018/03/03 06:11:12, CodingCat <coding...@apache.org> 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/list.html?d...@mxnet.apache.org: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 > > > > > >
