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