Re: JIRA configuration changes

[Ran Ziv]

John is it ok if we move on with this?
If so, could you please add another comment to the JIRA asking them to go
ahead with it?

Do you perhaps happen to know anyone on the infra team personally that we
could get to do these simple changes?

On Tue, Nov 15, 2016 at 11:17 AM, Maxim Orlov  wrote:

> +1 good points, could be really helpful
>
> On Mon, Nov 14, 2016 at 10:58 PM, Avia Efrat  wrote:
>
> > Overall, Ran's suggestions go well with my vision of the development
> > process.
> > I just want to further emphasize, the less options and fields in a Jira
> > issue screen (as long as it suits our general needs), the better.
> >
> > On Mon, Nov 14, 2016 at 10:04 PM, Ran Ziv  wrote:
> >
> > > 1) AFAIK in JIRA this is only possible using custom screens and fields.
> > > Even if those already exist in ASF JIRA, I'd rather not deviate too
> much
> > > from the default configuration, as explained before, though it's not
> > > something I strongly oppose or so.
> > >
> > > 2) I think you'll see our ARIA when searching for ARIA when we drop the
> > > aria-ng repo and move our website to the apache one :)
> > > In any case, again, this is merely the project's *key*. if im not
> > mistaken
> > > the project name can actually even remain ARIATOSCA.
> > >
> > > 3) It doesn't AFAIK - it's true that some fields are necessary for
> using
> > > the agile scrum board, but the issue type scheme is not part of that.
> > >
> > > On Mon, Nov 14, 2016 at 9:53 PM, John D. Ament 
> > > wrote:
> > >
> > > > On Mon, Nov 14, 2016 at 2:29 PM Ran Ziv  wrote:
> > > >
> > > > > John -
> > > > >
> > > > > 1) You can see the fields that are on these screens by default and
> > > > subtract
> > > > > the ones I asked to be removed. Regarding your suggestion about
> > > "affected
> > > > > version" - in an ideal world, I'd obviously agree - and this is
> > indeed
> > > > what
> > > > > I had in previous JIRAs I've worked with - but this so simple to do
> > in
> > > > JIRA
> > > > > actually, and requires custom screens, which usually lead to custom
> > > > fields,
> > > > > and that's one slippery slope I'd rather we just avoid altogether.
> > As I
> > > > > mentioned, the theme was to make things simpler, while keeping the
> > > making
> > > > > process simple :)
> > > > > I've checked out several other Apache projects, and all of them
> have
> > > > fields
> > > > > which are redundant for some issue types.
> > > > >
> > > >
> > > > You're assuming the issue type scheme doesn't have any field
> > settings.  I
> > > > can't say for certain whether they do or do not in ASF's JIRA.
> > > >
> > > >
> > > > >
> > > > >
> > > > > 2) ARIATOSCA is the project's name because of what you've
> mentioned,
> > > but
> > > > I
> > > > > see no reason why this should be confusing for anyone using ARIA or
> > > > having
> > > > > heard about TOSCA. This is a mere technical issue, and could go a
> > long
> > > > way
> > > > > for making our lives easier.
> > > > >
> > > >
> > > > https://www.google.com/search?q=aria
> > > > https://www.google.com/search?q=tosca
> > > >
> > > > I see our "TOSCA" as the third search result for tosca, but nothing
> > about
> > > > our ARIA when searching for ARIA, hence where I see confusion.
> > > >
> > > >
> > > > >
> > > > >
> > > > > 3) Not sure I see the conflict here. From my experience in agile
> > > > projects,
> > > > > the issue scheme I suggested fits just fine as well, and
> > "improvement"
> > > > and
> > > > > "wish" tend to only cause confusion and make things harder to
> filter
> > > etc.
> > > > >
> > > >
> > > > What I'm trying to draw out is if you've checked to make sure that
> the
> > > JIRA
> > > > configuration for Agile doesn't expect those issue types.
> > > >
> > > >
> > > > >
> > > > >
> > > > > 4) I completely understand your concern, and indeed I mean for this
> > > data
> > > > to
> > > > > be public knowledge, and for outside contributers to be allowed in
> > the
> > > > > "sprint" if/when necessary (and only if they'd be interested in
> it).
> > > > >
> > > > >
> > > > > Ran
> > > > >
> > > > >
> > > > > On Mon, Nov 14, 2016 at 9:19 PM, John D. Ament <
> > johndam...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Nov 14, 2016 at 1:54 PM Ran Ziv 
> > wrote:
> > > > > >
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > > So over a month ago I created this JIRA ticket
> > > > > > >  for the
> > Apache
> > > > > infra
> > > > > > > team, asking them to make several adjustments in our JIRA
> > > > > configuration.
> > > > > > >
> > > > > > > It still hasn't been taken care of, but in any case John has
> > > brought
> > > > it
> > > > > > to
> > > > > > > my attention that these suggestions should be discussed here as
> > > well
> > > > > > (back
> > > > > > > then we were pretty new to Apache, and I thought 

Re: JIRA configuration changes

[Maxim Orlov]

+1 good points, could be really helpful

On Mon, Nov 14, 2016 at 10:58 PM, Avia Efrat  wrote:

> Overall, Ran's suggestions go well with my vision of the development
> process.
> I just want to further emphasize, the less options and fields in a Jira
> issue screen (as long as it suits our general needs), the better.
>
> On Mon, Nov 14, 2016 at 10:04 PM, Ran Ziv  wrote:
>
> > 1) AFAIK in JIRA this is only possible using custom screens and fields.
> > Even if those already exist in ASF JIRA, I'd rather not deviate too much
> > from the default configuration, as explained before, though it's not
> > something I strongly oppose or so.
> >
> > 2) I think you'll see our ARIA when searching for ARIA when we drop the
> > aria-ng repo and move our website to the apache one :)
> > In any case, again, this is merely the project's *key*. if im not
> mistaken
> > the project name can actually even remain ARIATOSCA.
> >
> > 3) It doesn't AFAIK - it's true that some fields are necessary for using
> > the agile scrum board, but the issue type scheme is not part of that.
> >
> > On Mon, Nov 14, 2016 at 9:53 PM, John D. Ament 
> > wrote:
> >
> > > On Mon, Nov 14, 2016 at 2:29 PM Ran Ziv  wrote:
> > >
> > > > John -
> > > >
> > > > 1) You can see the fields that are on these screens by default and
> > > subtract
> > > > the ones I asked to be removed. Regarding your suggestion about
> > "affected
> > > > version" - in an ideal world, I'd obviously agree - and this is
> indeed
> > > what
> > > > I had in previous JIRAs I've worked with - but this so simple to do
> in
> > > JIRA
> > > > actually, and requires custom screens, which usually lead to custom
> > > fields,
> > > > and that's one slippery slope I'd rather we just avoid altogether.
> As I
> > > > mentioned, the theme was to make things simpler, while keeping the
> > making
> > > > process simple :)
> > > > I've checked out several other Apache projects, and all of them have
> > > fields
> > > > which are redundant for some issue types.
> > > >
> > >
> > > You're assuming the issue type scheme doesn't have any field
> settings.  I
> > > can't say for certain whether they do or do not in ASF's JIRA.
> > >
> > >
> > > >
> > > >
> > > > 2) ARIATOSCA is the project's name because of what you've mentioned,
> > but
> > > I
> > > > see no reason why this should be confusing for anyone using ARIA or
> > > having
> > > > heard about TOSCA. This is a mere technical issue, and could go a
> long
> > > way
> > > > for making our lives easier.
> > > >
> > >
> > > https://www.google.com/search?q=aria
> > > https://www.google.com/search?q=tosca
> > >
> > > I see our "TOSCA" as the third search result for tosca, but nothing
> about
> > > our ARIA when searching for ARIA, hence where I see confusion.
> > >
> > >
> > > >
> > > >
> > > > 3) Not sure I see the conflict here. From my experience in agile
> > > projects,
> > > > the issue scheme I suggested fits just fine as well, and
> "improvement"
> > > and
> > > > "wish" tend to only cause confusion and make things harder to filter
> > etc.
> > > >
> > >
> > > What I'm trying to draw out is if you've checked to make sure that the
> > JIRA
> > > configuration for Agile doesn't expect those issue types.
> > >
> > >
> > > >
> > > >
> > > > 4) I completely understand your concern, and indeed I mean for this
> > data
> > > to
> > > > be public knowledge, and for outside contributers to be allowed in
> the
> > > > "sprint" if/when necessary (and only if they'd be interested in it).
> > > >
> > > >
> > > > Ran
> > > >
> > > >
> > > > On Mon, Nov 14, 2016 at 9:19 PM, John D. Ament <
> johndam...@apache.org>
> > > > wrote:
> > > >
> > > > > On Mon, Nov 14, 2016 at 1:54 PM Ran Ziv 
> wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > So over a month ago I created this JIRA ticket
> > > > > >  for the
> Apache
> > > > infra
> > > > > > team, asking them to make several adjustments in our JIRA
> > > > configuration.
> > > > > >
> > > > > > It still hasn't been taken care of, but in any case John has
> > brought
> > > it
> > > > > to
> > > > > > my attention that these suggestions should be discussed here as
> > well
> > > > > (back
> > > > > > then we were pretty new to Apache, and I thought asking one of
> the
> > > > > mentors
> > > > > > to create the ticket could have sufficed).
> > > > > >
> > > > > >
> > > > > >
> > > > > > The general theme of the requested changes is about simplifying
> the
> > > > > > process, while at the same time not deviating too much from the
> > > default
> > > > > > configuration, so not to complicate things from the other end.
> > > > > >
> > > > > >
> > > > > > The specific changes I asked for are:
> > > > > >
> > > > > > 1) Removing unnecessary fields from the create-issue and
> > > resolve-issue
> > > > > > screens - the default screens are 

Re: JIRA configuration changes

[Ran Ziv]

1) AFAIK in JIRA this is only possible using custom screens and fields.
Even if those already exist in ASF JIRA, I'd rather not deviate too much
from the default configuration, as explained before, though it's not
something I strongly oppose or so.

2) I think you'll see our ARIA when searching for ARIA when we drop the
aria-ng repo and move our website to the apache one :)
In any case, again, this is merely the project's *key*. if im not mistaken
the project name can actually even remain ARIATOSCA.

3) It doesn't AFAIK - it's true that some fields are necessary for using
the agile scrum board, but the issue type scheme is not part of that.

On Mon, Nov 14, 2016 at 9:53 PM, John D. Ament 
wrote:

> On Mon, Nov 14, 2016 at 2:29 PM Ran Ziv  wrote:
>
> > John -
> >
> > 1) You can see the fields that are on these screens by default and
> subtract
> > the ones I asked to be removed. Regarding your suggestion about "affected
> > version" - in an ideal world, I'd obviously agree - and this is indeed
> what
> > I had in previous JIRAs I've worked with - but this so simple to do in
> JIRA
> > actually, and requires custom screens, which usually lead to custom
> fields,
> > and that's one slippery slope I'd rather we just avoid altogether. As I
> > mentioned, the theme was to make things simpler, while keeping the making
> > process simple :)
> > I've checked out several other Apache projects, and all of them have
> fields
> > which are redundant for some issue types.
> >
>
> You're assuming the issue type scheme doesn't have any field settings.  I
> can't say for certain whether they do or do not in ASF's JIRA.
>
>
> >
> >
> > 2) ARIATOSCA is the project's name because of what you've mentioned, but
> I
> > see no reason why this should be confusing for anyone using ARIA or
> having
> > heard about TOSCA. This is a mere technical issue, and could go a long
> way
> > for making our lives easier.
> >
>
> https://www.google.com/search?q=aria
> https://www.google.com/search?q=tosca
>
> I see our "TOSCA" as the third search result for tosca, but nothing about
> our ARIA when searching for ARIA, hence where I see confusion.
>
>
> >
> >
> > 3) Not sure I see the conflict here. From my experience in agile
> projects,
> > the issue scheme I suggested fits just fine as well, and "improvement"
> and
> > "wish" tend to only cause confusion and make things harder to filter etc.
> >
>
> What I'm trying to draw out is if you've checked to make sure that the JIRA
> configuration for Agile doesn't expect those issue types.
>
>
> >
> >
> > 4) I completely understand your concern, and indeed I mean for this data
> to
> > be public knowledge, and for outside contributers to be allowed in the
> > "sprint" if/when necessary (and only if they'd be interested in it).
> >
> >
> > Ran
> >
> >
> > On Mon, Nov 14, 2016 at 9:19 PM, John D. Ament 
> > wrote:
> >
> > > On Mon, Nov 14, 2016 at 1:54 PM Ran Ziv  wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > So over a month ago I created this JIRA ticket
> > > >  for the Apache
> > infra
> > > > team, asking them to make several adjustments in our JIRA
> > configuration.
> > > >
> > > > It still hasn't been taken care of, but in any case John has brought
> it
> > > to
> > > > my attention that these suggestions should be discussed here as well
> > > (back
> > > > then we were pretty new to Apache, and I thought asking one of the
> > > mentors
> > > > to create the ticket could have sufficed).
> > > >
> > > >
> > > >
> > > > The general theme of the requested changes is about simplifying the
> > > > process, while at the same time not deviating too much from the
> default
> > > > configuration, so not to complicate things from the other end.
> > > >
> > > >
> > > > The specific changes I asked for are:
> > > >
> > > > 1) Removing unnecessary fields from the create-issue and
> resolve-issue
> > > > screens - the default screens are cumbersome with fields that aren't
> > > > relevant for our project at this time. You can see the specific
> fields
> > in
> > > > the JIRA. Seems pretty straightforward to me.
> > > > The only field that's worth noting here is "Fix Version", which is
> > > > ambiguous in JIRA - some projects use it as "the version i'll fix
> this
> > > > issue for" (i.e. planning) and others as "the version in which the
> > issue
> > > > was fixed". I strongly prefer we use the latter one - it makes more
> > sense
> > > > for an open source, community project, and is actually known at the
> > time
> > > > where it is set.
> > > >
> > >
> > > Its not clear from this description what fields you're expecting or not
> > > expecting on the create issue screen.  Its also not clear what issue
> > types
> > > get what fields.  Could you elaborate on that further?  For instance, I
> > > would expect that an "Affects Version" field is present on bugs, but
> 

Re: JIRA configuration changes

[Tal Liron]

+1

Regarding sprints -- seems to me that this field can be used by whomever is
assigned the JIRA for their own purposes, whether they are in GigaSpaces or
not. As Ran pointed out, our own work is public.

On Mon, Nov 14, 2016 at 1:53 PM, John D. Ament 
wrote:

> On Mon, Nov 14, 2016 at 2:29 PM Ran Ziv  wrote:
>
> > John -
> >
> > 1) You can see the fields that are on these screens by default and
> subtract
> > the ones I asked to be removed. Regarding your suggestion about "affected
> > version" - in an ideal world, I'd obviously agree - and this is indeed
> what
> > I had in previous JIRAs I've worked with - but this so simple to do in
> JIRA
> > actually, and requires custom screens, which usually lead to custom
> fields,
> > and that's one slippery slope I'd rather we just avoid altogether. As I
> > mentioned, the theme was to make things simpler, while keeping the making
> > process simple :)
> > I've checked out several other Apache projects, and all of them have
> fields
> > which are redundant for some issue types.
> >
>
> You're assuming the issue type scheme doesn't have any field settings.  I
> can't say for certain whether they do or do not in ASF's JIRA.
>
>
> >
> >
> > 2) ARIATOSCA is the project's name because of what you've mentioned, but
> I
> > see no reason why this should be confusing for anyone using ARIA or
> having
> > heard about TOSCA. This is a mere technical issue, and could go a long
> way
> > for making our lives easier.
> >
>
> https://www.google.com/search?q=aria
> https://www.google.com/search?q=tosca
>
> I see our "TOSCA" as the third search result for tosca, but nothing about
> our ARIA when searching for ARIA, hence where I see confusion.
>
>
> >
> >
> > 3) Not sure I see the conflict here. From my experience in agile
> projects,
> > the issue scheme I suggested fits just fine as well, and "improvement"
> and
> > "wish" tend to only cause confusion and make things harder to filter etc.
> >
>
> What I'm trying to draw out is if you've checked to make sure that the JIRA
> configuration for Agile doesn't expect those issue types.
>
>
> >
> >
> > 4) I completely understand your concern, and indeed I mean for this data
> to
> > be public knowledge, and for outside contributers to be allowed in the
> > "sprint" if/when necessary (and only if they'd be interested in it).
> >
> >
> > Ran
> >
> >
> > On Mon, Nov 14, 2016 at 9:19 PM, John D. Ament 
> > wrote:
> >
> > > On Mon, Nov 14, 2016 at 1:54 PM Ran Ziv  wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > So over a month ago I created this JIRA ticket
> > > >  for the Apache
> > infra
> > > > team, asking them to make several adjustments in our JIRA
> > configuration.
> > > >
> > > > It still hasn't been taken care of, but in any case John has brought
> it
> > > to
> > > > my attention that these suggestions should be discussed here as well
> > > (back
> > > > then we were pretty new to Apache, and I thought asking one of the
> > > mentors
> > > > to create the ticket could have sufficed).
> > > >
> > > >
> > > >
> > > > The general theme of the requested changes is about simplifying the
> > > > process, while at the same time not deviating too much from the
> default
> > > > configuration, so not to complicate things from the other end.
> > > >
> > > >
> > > > The specific changes I asked for are:
> > > >
> > > > 1) Removing unnecessary fields from the create-issue and
> resolve-issue
> > > > screens - the default screens are cumbersome with fields that aren't
> > > > relevant for our project at this time. You can see the specific
> fields
> > in
> > > > the JIRA. Seems pretty straightforward to me.
> > > > The only field that's worth noting here is "Fix Version", which is
> > > > ambiguous in JIRA - some projects use it as "the version i'll fix
> this
> > > > issue for" (i.e. planning) and others as "the version in which the
> > issue
> > > > was fixed". I strongly prefer we use the latter one - it makes more
> > sense
> > > > for an open source, community project, and is actually known at the
> > time
> > > > where it is set.
> > > >
> > >
> > > Its not clear from this description what fields you're expecting or not
> > > expecting on the create issue screen.  Its also not clear what issue
> > types
> > > get what fields.  Could you elaborate on that further?  For instance, I
> > > would expect that an "Affects Version" field is present on bugs, but
> not
> > on
> > > stories (story is by definition new feature).
> > >
> > >
> > >
> > > >
> > > >
> > > > 2) Changing the project's JIRA key from "ARIATOSCA" to "ARIA" - this
> is
> > > > relevant for commit messages, as the key is used to link from JIRA
> > > tickets
> > > > to commits. Since the title line must start with this, but also be
> > > limited
> > > > to 50 characters, ARIA is much cleaner in this sense.
> > > > John has raised 

Re: JIRA configuration changes

[Ran Ziv]

John -

1) You can see the fields that are on these screens by default and subtract
the ones I asked to be removed. Regarding your suggestion about "affected
version" - in an ideal world, I'd obviously agree - and this is indeed what
I had in previous JIRAs I've worked with - but this so simple to do in JIRA
actually, and requires custom screens, which usually lead to custom fields,
and that's one slippery slope I'd rather we just avoid altogether. As I
mentioned, the theme was to make things simpler, while keeping the making
process simple :)
I've checked out several other Apache projects, and all of them have fields
which are redundant for some issue types.


2) ARIATOSCA is the project's name because of what you've mentioned, but I
see no reason why this should be confusing for anyone using ARIA or having
heard about TOSCA. This is a mere technical issue, and could go a long way
for making our lives easier.


3) Not sure I see the conflict here. From my experience in agile projects,
the issue scheme I suggested fits just fine as well, and "improvement" and
"wish" tend to only cause confusion and make things harder to filter etc.


4) I completely understand your concern, and indeed I mean for this data to
be public knowledge, and for outside contributers to be allowed in the
"sprint" if/when necessary (and only if they'd be interested in it).


Ran


On Mon, Nov 14, 2016 at 9:19 PM, John D. Ament 
wrote:

> On Mon, Nov 14, 2016 at 1:54 PM Ran Ziv  wrote:
>
> > Hi everyone,
> >
> > So over a month ago I created this JIRA ticket
> >  for the Apache infra
> > team, asking them to make several adjustments in our JIRA configuration.
> >
> > It still hasn't been taken care of, but in any case John has brought it
> to
> > my attention that these suggestions should be discussed here as well
> (back
> > then we were pretty new to Apache, and I thought asking one of the
> mentors
> > to create the ticket could have sufficed).
> >
> >
> >
> > The general theme of the requested changes is about simplifying the
> > process, while at the same time not deviating too much from the default
> > configuration, so not to complicate things from the other end.
> >
> >
> > The specific changes I asked for are:
> >
> > 1) Removing unnecessary fields from the create-issue and resolve-issue
> > screens - the default screens are cumbersome with fields that aren't
> > relevant for our project at this time. You can see the specific fields in
> > the JIRA. Seems pretty straightforward to me.
> > The only field that's worth noting here is "Fix Version", which is
> > ambiguous in JIRA - some projects use it as "the version i'll fix this
> > issue for" (i.e. planning) and others as "the version in which the issue
> > was fixed". I strongly prefer we use the latter one - it makes more sense
> > for an open source, community project, and is actually known at the time
> > where it is set.
> >
>
> Its not clear from this description what fields you're expecting or not
> expecting on the create issue screen.  Its also not clear what issue types
> get what fields.  Could you elaborate on that further?  For instance, I
> would expect that an "Affects Version" field is present on bugs, but not on
> stories (story is by definition new feature).
>
>
>
> >
> >
> > 2) Changing the project's JIRA key from "ARIATOSCA" to "ARIA" - this is
> > relevant for commit messages, as the key is used to link from JIRA
> tickets
> > to commits. Since the title line must start with this, but also be
> limited
> > to 50 characters, ARIA is much cleaner in this sense.
> > John has raised concern about TM/copyright issues etc., but I'm not sure
> > why this should be relevant when it's merely the JIRA project's key.
> >
> >
> There is in general a 1:1 relationship between apache projects and their
> JIRA issue key.  Almost always, the JIRA issue key is the project's name.
> There's been a couple of cases due to length where its had to be adjusted.
> In my opinion it creates confusion for them to be different.
>
> If we did rename the project to "ARIA" (this came up after being accepted
> into the incubator) its an issue.  I see "ARIA" out there a lot, its not a
> defendable name.
>
>
> >
> > 3) I asked to have our issue types the same as the "Aurora types scheme"
> > (see here
> >  Issue+Type+Schemes
> > >)
> > - It's the most simplified one which was already available on Apache -
> > which exactly follows the theme I've mentioned above. It also makes much
> > sense, as there's no mixup in between two similar types (e.g. improvement
> > vs story, wish vs feature, etc.) - which IMO far outweighs missing a very
> > specific issue type.
> > Epic, Bug, Story, are all well defined. Sub-tasks are technical tasks and
> > can be used to divide any bug, story or task into smaller parts. And
> > finally Task can be used for 

Re: JIRA configuration changes

[Dan Kilman]

+1
sounds like solid suggestion to me

On Mon, Nov 14, 2016 at 8:54 PM, Ran Ziv  wrote:

> Hi everyone,
>
> So over a month ago I created this JIRA ticket
>  for the Apache infra
> team, asking them to make several adjustments in our JIRA configuration.
>
> It still hasn't been taken care of, but in any case John has brought it to
> my attention that these suggestions should be discussed here as well (back
> then we were pretty new to Apache, and I thought asking one of the mentors
> to create the ticket could have sufficed).
>
>
>
> The general theme of the requested changes is about simplifying the
> process, while at the same time not deviating too much from the default
> configuration, so not to complicate things from the other end.
>
>
> The specific changes I asked for are:
>
> 1) Removing unnecessary fields from the create-issue and resolve-issue
> screens - the default screens are cumbersome with fields that aren't
> relevant for our project at this time. You can see the specific fields in
> the JIRA. Seems pretty straightforward to me.
> The only field that's worth noting here is "Fix Version", which is
> ambiguous in JIRA - some projects use it as "the version i'll fix this
> issue for" (i.e. planning) and others as "the version in which the issue
> was fixed". I strongly prefer we use the latter one - it makes more sense
> for an open source, community project, and is actually known at the time
> where it is set.
>
>
> 2) Changing the project's JIRA key from "ARIATOSCA" to "ARIA" - this is
> relevant for commit messages, as the key is used to link from JIRA tickets
> to commits. Since the title line must start with this, but also be limited
> to 50 characters, ARIA is much cleaner in this sense.
> John has raised concern about TM/copyright issues etc., but I'm not sure
> why this should be relevant when it's merely the JIRA project's key.
>
>
> 3) I asked to have our issue types the same as the "Aurora types scheme"
> (see here
>  >)
> - It's the most simplified one which was already available on Apache -
> which exactly follows the theme I've mentioned above. It also makes much
> sense, as there's no mixup in between two similar types (e.g. improvement
> vs story, wish vs feature, etc.) - which IMO far outweighs missing a very
> specific issue type.
> Epic, Bug, Story, are all well defined. Sub-tasks are technical tasks and
> can be used to divide any bug, story or task into smaller parts. And
> finally Task can be used for any technical task, whether it's a tech debt,
> missing test, documentation task, etc.
>
>
> 4) I asked for a sprint board to be created for the project. I asked it to
> be a standard scrum one, with story points etc.; Also seems pretty
> straightforward to me really.
>
>
>
> Please let me know if anyone has any issues with any of the change
> suggestions above so I could update my ticket accordingly.
> I would really like this ticket not to be delayed any further so lets
> decide quickly on this.
>
>
> Thanks,
> Ran
>

JIRA configuration changes

[Ran Ziv]

Hi everyone,

So over a month ago I created this JIRA ticket
 for the Apache infra
team, asking them to make several adjustments in our JIRA configuration.

It still hasn't been taken care of, but in any case John has brought it to
my attention that these suggestions should be discussed here as well (back
then we were pretty new to Apache, and I thought asking one of the mentors
to create the ticket could have sufficed).



The general theme of the requested changes is about simplifying the
process, while at the same time not deviating too much from the default
configuration, so not to complicate things from the other end.


The specific changes I asked for are:

1) Removing unnecessary fields from the create-issue and resolve-issue
screens - the default screens are cumbersome with fields that aren't
relevant for our project at this time. You can see the specific fields in
the JIRA. Seems pretty straightforward to me.
The only field that's worth noting here is "Fix Version", which is
ambiguous in JIRA - some projects use it as "the version i'll fix this
issue for" (i.e. planning) and others as "the version in which the issue
was fixed". I strongly prefer we use the latter one - it makes more sense
for an open source, community project, and is actually known at the time
where it is set.


2) Changing the project's JIRA key from "ARIATOSCA" to "ARIA" - this is
relevant for commit messages, as the key is used to link from JIRA tickets
to commits. Since the title line must start with this, but also be limited
to 50 characters, ARIA is much cleaner in this sense.
John has raised concern about TM/copyright issues etc., but I'm not sure
why this should be relevant when it's merely the JIRA project's key.


3) I asked to have our issue types the same as the "Aurora types scheme"
(see here
)
- It's the most simplified one which was already available on Apache -
which exactly follows the theme I've mentioned above. It also makes much
sense, as there's no mixup in between two similar types (e.g. improvement
vs story, wish vs feature, etc.) - which IMO far outweighs missing a very
specific issue type.
Epic, Bug, Story, are all well defined. Sub-tasks are technical tasks and
can be used to divide any bug, story or task into smaller parts. And
finally Task can be used for any technical task, whether it's a tech debt,
missing test, documentation task, etc.


4) I asked for a sprint board to be created for the project. I asked it to
be a standard scrum one, with story points etc.; Also seems pretty
straightforward to me really.



Please let me know if anyone has any issues with any of the change
suggestions above so I could update my ticket accordingly.
I would really like this ticket not to be delayed any further so lets
decide quickly on this.


Thanks,
Ran