+1 good points, could be really helpful On Mon, Nov 14, 2016 at 10:58 PM, Avia Efrat <a...@gigaspaces.com> 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 <r...@gigaspaces.com> 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 <johndam...@apache.org> > > wrote: > > > > > On Mon, Nov 14, 2016 at 2:29 PM Ran Ziv <r...@gigaspaces.com> 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 <r...@gigaspaces.com> > wrote: > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > So over a month ago I created this JIRA ticket > > > > > > <https://issues.apache.org/jira/browse/INFRA-12733> 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 > > > > > > <https://cwiki.apache.org/confluence/display/INFRA/Jira+ > > > > > 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 any technical task, whether it's a > > tech > > > > > debt, > > > > > > missing test, documentation task, etc. > > > > > > > > > > > > > > > > I agree, however 3 & 4 seem to conflict. "Agile Scrum Issue Type" > > > Scheme > > > > > most correctly manages an agile dev effort. The only real > difference > > > is > > > > > Improvement & Wish issue types, which are more planning level items > > to > > > > get > > > > > some refinement prior to being implemented. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > My only concern here is that it reflects very closely a tight > > > correlation > > > > > between gigaspaces and the project. Will your planning data be > > public > > > > > knowledge? What happens when you have outside contributors? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
