Looking at the ticket you linked it seems it easy for infra to make this change. As long as its not a hassle for infra I would be in favor of changing it back.
The problem w/ issues being assigned to people who are not working on them (it seems this is sparks concern) applies to commiters and contributors. It seems like a simple solution to that is some documentation on our web site encouraging people to contact the person a ticket is assigned to if they are interested in working on it. On Wed, May 14, 2014 at 4:38 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
I like that flow. I'm very much against not letting contributors assign tickets. If you have a problem with "old" contributors "stealing" tickets from new contributors, then that needs to be handled with best practices documentation and/or explicit coaching. Locking down who can assign tickets is a poor way of managing a misbehaving community. As we grow the community, we need to give more opportunities for contributors to show their judgement on both technical and project decisions. Holding back the ability to assign tickets makes that more difficult.
On Thu, May 15, 2014 at 9:15 AM, Sean Busbey <[EMAIL PROTECTED]> wrote:
That looks like an accurate representation of the informal process. +1 for letting them assign themselves
Aside about #7: If this process gets documented in a contributor section of the website (which, maybe it should?) or a wiki, or whatever, I'd want to just add note that when looking for tickets to work on, they do not have to shy away from something, just because it is currently assigned to somebody else. Rather, they could seek out a collaboration, or check on the status and see if it's actively being worked on. This comment might be helpful to such a document, because we all know the JIRA is not always up-to-date, and that tickets may be assigned for other reasons.
Luckily, I believe we are not affected by the change because we are using the Hadoop Permissions scheme in JIRA and not the ASF defaults. For a first-time contributor, I don't think it makes much difference whether we assign the ticket or they do. But it seems better for existing contributors to be allowed to assign additional tickets to themselves without having to ask someone to do it for them. I don't think we've seen any abuse of ticket-assigning privileges (and in fact it's hard to imagine what that would look like). On Wed, May 14, 2014 at 1:38 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
As a contributor, I like this approach. I'm able to through and assign an issue to myself without pestering anyone else.
I like the incentive-based approach for prospective contributors: have a committer assign an issue to a user after they express interest in working it, then give them contributor status after they submit their first patch.
That's how I experienced it the first time. The positive reinforcement was a good thing.
On Wed, May 14, 2014 at 1:38 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext