[wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas

[Steve Ebersole]

If triaging is a big concern, keeping the default assignee is one way to
help make sure the triage happens (supposing it does now).  Just because
something is default assigned to you does not mean it has to stay that way
- triage it and re-assign, un-assign, reject, etc

On Thu, Mar 29, 2018 at 12:35 PM Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

> When the default is gonna be unassigned for WFLY and WFCORE, following
> pages should get better visibility:
>
>  -
> https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page
>  -
> https://issues.jboss.org/projects/WFCORE?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page
>
> Reason is to have easy way how to identify component owner when there is
> lack of activity on the issue.
>
> Rostislav
> On Thu, Mar 29, 2018 at 5:15 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> There's nothing stopping leads (or others) from commenting on issues
>> with questions and/or more information, also.  I'm more inclined to do
>> that when I look at an issue and think "this isn't assigned to me, so
>> I better make a note for whoever works the issue instead of just
>> writing it on a forgotten notepad somewhere".  Even if it ends up
>> being me, it's helpful.
>>
>> On Thu, Mar 29, 2018 at 9:58 AM, Brian Stansberry
>> <brian.stansberry at redhat.com> wrote:
>> > I'm in favor of this change.
>> >
>> > I think in most cases it's important for people to communicate with
>> > component leads before they start doing much on an issue. But having the
>> > issued assigned to the lead hasn't AFAICT help ensure that kind of
>> > communication.
>> >
>> > On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller <anmiller at redhat.com>
>> wrote:
>> >>
>> >> Good points.  The issue has always been getting component leads to
>> triage
>> >> their issues on a regular enough basis.
>> >>
>> >> If this is just hiding that problem, and causing issues with community
>> >> involvement, I am all for going back to unassigned.
>> >>
>> >> Andy
>> >>
>> >> On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd <david.lloyd at redhat.com>
>> >> wrote:
>> >>>
>> >>> Speaking for myself, I'd rather have issues unassigned because having
>> >>> it assigned means "do not work on this; someone else is going to".
>> >>> Then they just sit like that, maybe for years.
>> >>>
>> >>> I think having a default assignee is hiding the symptom while at the
>> >>> same time discouraging volunteers from taking issues.  It's even worse
>> >>> now that we have multiple teams within Red Hat itself who want to work
>> >>> issues.  I often get emails like "I see that WFLY-xxx is assigned to
>> >>> you; is it OK if I take it?"  For every one of these, there may be
>> >>> several (internal or external) where they just give up because the
>> >>> issue is "assigned", and they just wait forever for someone to deliver
>> >>> the fix/feature for them.
>> >>>
>> >>> We see every issue as they are created.  If we don't take an issue at
>> >>> that time, being honest, are we really ever going to do it?
>> >>>
>> >>> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller <anmiller at redhat.com>
>> >>> wrote:
>> >>> > This is the way it was a long time ago, and then we moved to
>> default to
>> >>> > the
>> >>> > component lead because so many issues were being left in the
>> unassigned
>> >>> > state.
>> >>> >
>> >>> > Perhaps the default assignment just makes thing "look" better, and
>> >>> > doesn't
>> >>> > force triage to occur, or perhaps it does?
>> >>> >
>> >>> > I think we just think about this a little more, since we made the
>> >>> > change
>> >>> > because of such a mountain of issues being in the unassigned state.
>> >>> >
>> >>> > Andy
>> >>> >
>> >>> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd <
>> david.lloyd at redhat.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> This is something we've talked about before.  I think we should
>> move
>> >>> >> forward on this for the WFLY and WFCORE projects.
>> >>> >>
>> >>> >> Ideally we'd also have a "responsible person" field which would be
>> >>> >> populated by the component lead by default.  But I don't think
>> this is
>> >>> >> necessary as long as our component leads are triaging issues in
>> their
>> >>> >> areas (which they should be).
>> >>> >>
>> >>> >> I think we should just do it.  WDYT?
>> >>> >>
>> >>> >> --
>> >>> >> - DML
>> >>> >> _______________________________________________
>> >>> >> wildfly-dev mailing list
>> >>> >> wildfly-dev at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Andrig (Andy) T. Miller
>> >>> > Global Platform Director, Middleware
>> >>> > Red Hat, Inc.
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> - DML
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Andrig (Andy) T. Miller
>> >> Global Platform Director, Middleware
>> >> Red Hat, Inc.
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> >
>> > --
>> > Brian Stansberry
>> > Manager, Senior Principal Software Engineer
>> > Red Hat
>>
>>
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180329/ad0795c0/attachment-0001.html