ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: JIRA Issue Scheme
Date Wed, 02 Nov 2016 02:29:05 GMT
Hi Ran,

Thanks for the insight.  The biggest I'm trying to point out is to have
open discussions on the mailing lists when making these types of
decisions.  I get that you guys at Gigaspaces are colocated and probably
talked about this in your office - would be good to also have the
discussion here. At some point I hope Aria grows beyond Gigaspaces
employees and in order for this to be a true team of individuals not just
representing corporate interests, those discussions are intended to happen
on the ML.

John

On Sun, Oct 30, 2016 at 6:30 PM Ran Ziv <ran@gigaspaces.com> wrote:

> The reason we asked for this is because we wanted to simplify some of the
> JIRA mechanisms (screens, issues) but with only requiring minimal changes
> from the defaults.
>
> From my experience having too many issue types makes it confusing for issue
> reporters to choose the right one (e.g. "story" vs "improvement").
>
> It's true that Documentation specifically is a valid type, but I wanted to
> ask for an existing issue types scheme rather than ask for the creation of
> a new one (partially because I was hoping for this to help in having this
> issue be dealt with quickly, which hasn't quite proven to be the case..).
> Under the current scheme, the right type for a documentation issue would be
> "Task", which seems fine to me, but I don't really feel too strongly about
> it either way.
>
> I do think types such as "test", "wish", "improvement" etc. are problematic
> though, and would rather not have them around :)
>
>
>
>
> On Sun, Oct 30, 2016 at 5:59 PM, John D. Ament <johndament@apache.org>
> wrote:
>
> > I just saw this ticket in the INFRA backlog -
> > https://issues.apache.org/jira/browse/INFRA-12733
> >
> > Just wondering, was this discussed on the ML?  I didn't see it, and I
> would
> > recommend leaving in ticket types like documentation.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message