Re: JIRA Issue Scheme

2016-11-01 Thread Ran Ziv
Yup, I completely understand.
It did however take that first time you pointed it out for me to realize
this though, and it's simply that the JIRA issue had been created before
then :)
I'll make sure all future communication goes through the mailing list.

On Wed, Nov 2, 2016 at 4:29 AM, John D. Ament  wrote:

> 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  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 
> > 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.
> > >
> >
>


Re: JIRA Issue Scheme

2016-11-01 Thread John D. Ament
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  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 
> 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.
> >
>