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

[Rostislav Svoboda]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180329/bfcf1fe7/attachment.html