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 <mnnav...@gmail.com> 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 <cjolivie...@gmail.com> > 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 < > 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 > > > > > > > > > > > > > > >
