Return-Path: X-Original-To: apmail-groovy-dev-archive@minotaur.apache.org Delivered-To: apmail-groovy-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4F517187DF for ; Fri, 15 Jan 2016 19:09:10 +0000 (UTC) Received: (qmail 50589 invoked by uid 500); 15 Jan 2016 19:09:09 -0000 Delivered-To: apmail-groovy-dev-archive@groovy.apache.org Received: (qmail 50546 invoked by uid 500); 15 Jan 2016 19:09:09 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 50536 invoked by uid 99); 15 Jan 2016 19:09:09 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Jan 2016 19:09:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 271651A01F2 for ; Fri, 15 Jan 2016 19:09:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.9 X-Spam-Level: *** X-Spam-Status: No, score=3.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id NmVmhVBwLzhc for ; Fri, 15 Jan 2016 19:09:00 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 84A8E42BA7 for ; Fri, 15 Jan 2016 19:09:00 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id ik10so19465633igb.1 for ; Fri, 15 Jan 2016 11:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yvLZiO1y0NBoBXcAV0j3F4BCEACQ3lYOCa+borhQN0Y=; b=WsAKQdE+nfbjdyMaL53NmoVTbDms3C0iuNh7HDZm0IjZUUbSNdskQ3/KwKOjCayj0u J9KnKCLsGTZkLP/TOvoy5AjxjDfQvotnUQ3yX+IEvgkPufx7LSIZ8EaitRRNK/LTyec2 YX3KKUckRkSS7adp8egZxVy26Do//Z6qxnBldrkpHmIfUjiuBMygDQXaKQde0oqCV9v4 bNanScs6G+PueSAFk2IrkvhYQs+KisKBJsjmAFKP5CHie2bA5Pj0WZsqVKRAcexs7MSq npCErB9nCYm1ZbzWOunWa3bvBI/ChtgEl8+1F0eg/4NvQ7l7CHEjC9YnkXjBchx6jtTF X6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yvLZiO1y0NBoBXcAV0j3F4BCEACQ3lYOCa+borhQN0Y=; b=ItJiIdkV7HUzG/ic+ruRUZX98/ZR8/faKcd0PY/C0esdHXAZaW5MwI/WA2PxC1X/3T BCHUqW/uIkMnIUw2k5qi6q1I9AfztGcpReXSANt4+hezui/YRKla2FToWXe8IRgIZdo+ gWCvig5PfzXJ2CHKbNO3AyUoPP6b6QSRr16lxo5lijILO6rV3YiJaLSdAf+RcafXxRRC sdIo/F8uZ7R5zIsbTZXKw5Xij1crfguz4ap22/O6qPTHXALJeoqkQlIJyb6qe3vlxlNk Aaj2EZPoLNBFzo9Nhbdj5I8xq8owltPoPbEZcCpXG4TFWrBQFaNtadPIkfQyB0e+aupl g1FA== X-Gm-Message-State: AG10YOR/YO6YiEgOBAot/oLC546KBPqX7bQK01EAwcj2LZqcApjAn1wP9LPKw63mgrsrECwriP9p+8e0lF5Yjg== MIME-Version: 1.0 X-Received: by 10.50.155.1 with SMTP id vs1mr182114igb.20.1452884940097; Fri, 15 Jan 2016 11:09:00 -0800 (PST) Received: by 10.64.126.169 with HTTP; Fri, 15 Jan 2016 11:09:00 -0800 (PST) In-Reply-To: References: <56993D9A.7080106@gmx.net> Date: Fri, 15 Jan 2016 20:09:00 +0100 Message-ID: Subject: Re: Disable auto-assignment of jira issues? From: Guillaume Laforge To: "dev@groovy.apache.org" Content-Type: multipart/alternative; boundary=001a11c1e7eac1163d05296422bd --001a11c1e7eac1163d05296422bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm fine with that too. Historically, there was often someone more focused on this or that part, and with JIRA components, we could pre-assign an issue so the person could handle it or triage it and route it to the right person. But it's more because JIRA allowed that that we did it, more than because that was the best way to deal with our tickets :-) I think we just need to remove JIRA component leads to avoid the auto assignment. Guillaume Le vendredi 15 janvier 2016, John Wagenleitner a =C3=A9crit : > I agree, I think turning off auto-assignment would be a good idea. > > +1 > > On Fri, Jan 15, 2016 at 10:42 AM, Pascal Schumacher < > pascalschumacher@gmx.net > > wrote: > >> Hello everybody, >> >> I think should disable auto-assignment of jira issues. Dozen of issues >> are assigned to people who do not currently work on them. I believe this >> stops people from contributing, because they think somebody is already >> working on the issue. It also mislead users to expect that the issue wil= l >> be fixed soon. >> >> What do you think? >> >> Cheers, >> Pascal >> > > --=20 Guillaume Laforge Apache Groovy committer & PMC member Product Ninja & Advocate at Restlet Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+ --001a11c1e7eac1163d05296422bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm fine with that too.
Historically, there was often someone more = focused on this or that part, and with JIRA components, we could pre-assign= an issue so the person could handle it or triage it and route it to the ri= ght person.
But it's more because JIRA allowed that that we d= id it, more than because that was the best way to deal with our tickets :-)=
I think we just need to remove JIRA component leads to avoid the= auto assignment.

Guillaume


Le= =C2=A0vendredi 15 janvier 2016, John Wagenleitner <john.wagenleitner@gmail.com> a =C3=A9crit= =C2=A0:
I agree, I think= turning off auto-assignment would be a good idea.=C2=A0

+1

On Fri, Jan 15= , 2016 at 10:42 AM, Pascal Schumacher <pascalschumacher@gmx.net> wrote:
Hello everybody,

I think should disable auto-assignment of jira issues. Dozen of issues are = assigned to people who do not currently work on them. I believe this stops = people from contributing, because they think somebody is already working on= the issue. It also mislead users to expect that the issue will be fixed so= on.

What do you think?

Cheers,
Pascal



--
Guillaume Laforge
Apache Groovy committe= r & PMC member
Product Ninja & Advocate at Restlet

--001a11c1e7eac1163d05296422bd--