RE: JIRA and communities
-Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Saturday, May 26, 2012 10:51 AM To: general@incubator.apache.org Subject: Re: JIRA and communities So, what message here should the incubator send a podling, or the foundation send a TLP? I really don't mean this as a rhetorical question at all, I'm honestly puzzled. In the case of Lucene, I've been hanging out for months, and I feel perfectly confident that it's a healthy community by any foundation standard. At the same time, you all are perfectly correct: watching them means dealing with a tsunami of trivia. I'm stumped at what suggestion, let alone demand, I'd deliver to such a community. IMO, we wouldn't want to force a single workflow into each community just because it appears to lower the barrier of entry. I fully understand how JIRA and ReviewBoard can pollute a mail list; however, if that is how the community wants to operate, why stop them? Since everything gets forwarded to the dev list, IMO JIRA and ReviewBoard are perfectly legitimate tools for managing workflows within communities. We can always suggest changes and simplifications, or try out new processes and workflows, but forcing a community to operate a specific way doesn't seem appropriate. One thing I have seen a few podlings do is add a users mail list that offers a lower barrier of entry and allows newcomers to gradually become more immersed in the daily operations of the project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On May 28, 2012, at 6:57 AM, Franklin, Matthew B. wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Saturday, May 26, 2012 10:51 AM To: general@incubator.apache.org Subject: Re: JIRA and communities So, what message here should the incubator send a podling, or the foundation send a TLP? I really don't mean this as a rhetorical question at all, I'm honestly puzzled. In the case of Lucene, I've been hanging out for months, and I feel perfectly confident that it's a healthy community by any foundation standard. At the same time, you all are perfectly correct: watching them means dealing with a tsunami of trivia. I'm stumped at what suggestion, let alone demand, I'd deliver to such a community. IMO, we wouldn't want to force a single workflow into each community just because it appears to lower the barrier of entry. I fully understand how JIRA and ReviewBoard can pollute a mail list; however, if that is how the community wants to operate, why stop them? Since everything gets forwarded to the dev list, IMO JIRA and ReviewBoard are perfectly legitimate tools for managing workflows within communities. We can always suggest changes and simplifications, or try out new processes and workflows, but forcing a community to operate a specific way doesn't seem appropriate. The problem here is that discussions and decisions are supposed to happen on the dev list. With ReviewBoard, while everything does get sent to the list, the discussion is extremely difficult to follow just by looking at the email. In fact, I'd wonder how many devs who are on projects that use ReviewBoard read those emails. As far as Flume goes, if you take away the Jira and ReviewBoard noise I'd guess more technical discussion takes place on the user's list than on the dev list. Of course, I haven't looked at the other projects that use it so I don't know if it is the same there. By the way, if anyone can tell me how to configure gmail to filter the ReviewBoard stuff so I can put it in its own folder I would greatly appreciate it. One thing I have seen a few podlings do is add a users mail list that offers a lower barrier of entry and allows newcomers to gradually become more immersed in the daily operations of the project. IMO, every project should have a user's list, but that is really more for end users who have questions on how to use the project. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
So, what message here should the incubator send a podling, or the foundation send a TLP? I really don't mean this as a rhetorical question at all, I'm honestly puzzled. In the case of Lucene, I've been hanging out for months, and I feel perfectly confident that it's a healthy community by any foundation standard. At the same time, you all are perfectly correct: watching them means dealing with a tsunami of trivia. I'm stumped at what suggestion, let alone demand, I'd deliver to such a community. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On Sat, May 26, 2012 at 7:51 AM, Benson Margulies bimargul...@gmail.com wrote: So, what message here should the incubator send a podling, or the foundation send a TLP? I really don't mean this as a rhetorical question at all, I'm honestly puzzled. There are a couple of technical mitigations which can help, such as disabling the ability to edit comments. I made another suggestion on the Infra list this morning regarding trimming context from JIRA notifications[1], but it turned out to be impractical given the strain of supporting JIRA already. I think the core issue is the tension between accessibility and the advantages of heavily customized workflow. Additionally, some people prefer to have conversations via web bulletin boards rather than email. That's hardly a new phenomenon. JIRA presents challenges because its email integration is awkward. It doesn't support replies, it uses a wiki markup language which doesn't translate well to plain text (compared to say, Markdown), it encourages really long lines, email content customization is not a first-class feature, and so on. The email integration of our JIRA workflows can be improved, but only to a certain extent. Perhaps one answer might be to create a competing system for patch contribution by integrating more closely with GitHub. I've done a little work building on what Jukka put in place for pull request notifications, and the GitHub API looks pretty flexible. If we make it easy to contribute patches via GitHub pull requests, and start capturing pull request comments to dev lists, then perhaps we'll have fewer conversations in JIRA. And unlike JIRA, we're not stuck with the limitations of a monolithic architecture -- our consumption of GitHub events happens via individual scripts. In the case of Lucene, I've been hanging out for months, and I feel perfectly confident that it's a healthy community by any foundation standard. At the same time, you all are perfectly correct: watching them means dealing with a tsunami of trivia. I'm stumped at what suggestion, let alone demand, I'd deliver to such a community. Lucene is at a different point in the product life cycle than most incoming podlings. Even if Lucene loses a few recruits, there are still plenty lining up to contribute -- thus there are fewer visible consequences if the project is not as inviting as it could be. I still think it would be worthwhile to pursue improvements for our JIRA based projects, though. For my own selfish reasons, I'd really like to follow Lucene dev discussions more closely, or be able to scan over Avro's dev list archives and figure out what on earth is going on. Marvin Humphrey [1] I suggested removing the nearly worthless inline summary context information which is repeated in every JIRA notification email. Sadly, this cannot be achieved using a plugin, and thus would make upgrading JIRA even more painful. Private archive of the thread here: http://s.apache.org/oJ [Any ASF committer can subscribe to infrastructure@a.o, but the archives are only accessible to full ASF Members, unfortunately.] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
Marvin, I am at your disposal to collaborate on something here; note my reply at infrastructure@. It seems to me that this thread would largely go better over there, now that the caveat that 'a podling run entirely on JIRA may have community problems' has been delivered. --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
JIRA and communities
On Fri, May 25, 2012 at 12:53 AM, Steve Loughran steve.lough...@gmail.com wrote: On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. Meanwhile, some projects, with or without JIRA, just creep along making small, incremental, changes and bugfixes. There's no grand strategy or vision, and, as a result, not much to talk about most of the time. Bugs and requests come in and people deal with them -- or not. So, I won't claim that your disfunction scenario is impossible or never observed at the ASF. I will point out that bugzilla could be used just as effectively to create the same problem. As a mentor, what I care about is what happens when a new person shows up. Does the dev list manage to welcome and encourage that person? Or does that person find a mysterious, opaque situation in which there seems to be a secret code that has to be broken to get a contribution accepted? If welcome and encouragement amounts to 'go find a JIRA and get busy,' that does not bother me, so long it leads to the happy result of applied patches and eventual karma. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On May 25, 2012, at 8:37 AM, Benson Margulies wrote: On Fri, May 25, 2012 at 12:53 AM, Steve Loughran steve.lough...@gmail.com wrote: On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. I have no problem with Jira, it is a great tool. My problem - specific to the way Flume does things - is that they also use the Review tool and you end up with a copy of a message from the Review tool and another copy of the same thing from Jira. A LOT of those messages are pure noise. The ones that do contain content do a poor job of quoting whatever is being commented on. So the only way to really tell what is going on is to go into Jira and look at every issue. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On Fri, May 25, 2012 at 8:37 AM, Benson Margulies bimargul...@gmail.com wrote: I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I claim it does both. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. I'm *really* interested in ongoing Lucene development, but I can't take following the Lucene dev list via email any more. The signal-to-noise ratio is horrible. Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack reassigned LUCENE-1040 Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:11 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:12 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:13 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:14 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:15 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:16 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:17 PM: V. de Gin created LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 Joe Sixpack reassigned LUCENE-5150 Joe Sixpack updated LUCENE-5150 It's a daily tsunami of trivia, redundant quotes, bloated diffs and butchered titles. (And then there are the dozens of Jenkins failure notifications, but I've figured out how to filter those.) For what it's worth, I recently considered exploring Apache Avro (the C implementation interests me), but the Avro dev list is similarly impenetrable and I gave up. Maybe I'll try again later... JIRA has its strengths, but its integration into mailing-list style development leaves much to be desired. So, I won't claim that your disfunction scenario is impossible or never observed at the ASF. I will point out that bugzilla could be used just as effectively to create the same problem. Sure. In a similar vein, there has been discussion about tighter integration with Github. We've been sending GitHub pull request notifications to ASF dev lists for a while now, and there's talk of mirroring pull request comments as well. If we handle the integration of Github comments as poorly as JIRA notifications, the potential exists to force new users to to learn Github's API in order to participate fully. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On May 25, 2012, at 10:32 AM, Ralph Goers wrote: On May 25, 2012, at 8:37 AM, Benson Margulies wrote: On Fri, May 25, 2012 at 12:53 AM, Steve Loughran steve.lough...@gmail.com wrote: On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. I have no problem with Jira, it is a great tool. My problem - specific to the way Flume does things - is that they also use the Review tool and you end up with a copy of a message from the Review tool and another copy of the same thing from Jira. A LOT of those messages are pure noise. The ones that do contain content do a poor job of quoting whatever is being commented on. So the only way to really tell what is going on is to go into Jira and look at every issue. In my quick review yesterday in the ML, it really was difficult. The combination between Review and JIRA is worse than getting non-html COnfluence notifications which don't diff. You cannot know what is going on without the other tools. Bugzilla and JIRA notifications by themselves aren't too bad, at least these are incremental. It really is hard not to think that all the work is being done in JIRA and ReviewBoard and not on the ML. This makes oversight difficult. Regards, Dave Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
