I notice Apache's Jira now nicely allows Epics to include Stories directly. In older versions you had to link the stories to the epics, which was cumbersome. See https://issues.apache.org/jira/browse/AIRAVATA-1150.
Vivek (and anyone else), please let me know if this is aligned with your email below. Marlon On 4/22/14 5:21 PM, Vivek Bhatia wrote: > Sorry I forgot to provide an example so doing that now. So based on > following comment from Suresh in the email related to the discussion we are > having regarding GFac's role. > > So I should write one plugin which works well for a single execution and > has been builtin checkpoint recovery at critical steps and then framework > should help me deal with multiple threads of these executions, logging, > recovery, call-back and so on. There should be a guideline of how the > contract between the framework and extensions. > > Theme - GFac 2.0 > Epic - PlugIn for GFac > Story - As a User I would like to build checkpoint recovery at critical > steps in the plugin. > Task - blah, blah... > > The component for this is GFac and others that we touch. > > Hope this helps! > > -Vivek > > > > > On Tue, Apr 22, 2014 at 2:12 PM, Vivek Bhatia <[email protected]> wrote: > >> Hi Suresh, >> >> Yes, I agree we should segregate major architectural changes. Ideally, we >> can view these as 2 separate areas. There are others as well but can start >> with these. >> >> 1. Work streams - These are projects/work items that every one works on. >> We need to establish a structure for these. For example following is one >> way to organize our work items. >> >> Themes - This is a high level view of tangible work/product/feature. This >> is sometimes also called a HLF (High Level Feature) >> |_ >> Epic - The themes are generally broken down into one or more Epic. An >> Epic is a block of requirements that have not been broken down on >> rationalized into stories. >> |_ >> Stories - These are brief statements for product requirements >> or use/business case. These are one level below the Epics in other words >> one or more stories under an Epic >> |_ >> Task - Tasks are at the most granular level and >> are a discreet piece of work. They define some effort or work that can be >> completed to satisfy the task. These roll up into a story. >> >> JIRA provides the capability for us to be able to build a structure like >> this. This will enable us to determine what and how much work we need to do >> to achieve what we are planning to achieve. This is a simplistic view and >> obviously more needs to be done but if we can implement this to begin with >> it will be a good start. For example, later on we can also track these work >> items using labels once the structure is established. >> >> 2. Architectural Components - These are architectural components that we >> work on as part of work items. We can define these in JIRA in the component >> field such as XBaya, GFac, etc. I noticed that we are already doing this. >> >> I can help with some of this effort but I do not have edit/create >> permissions on JIRA. I tried assigning a JIRA to myself but wasn't able. >> Additionally I wanted to log a JIRA for the common commands but couldn't do >> it. I think I will need permissions to do that. >> >> Thanks, >> -Vivek >> >> >> >> On Tue, Apr 22, 2014 at 1:39 PM, Suresh Marru <[email protected]> wrote: >> >>> Hi Vivek, >>> >>> I think this is a great suggestion. I agree and second everything you say >>> below. >>> >>> Should we also consider segregating major architectural changes, >>> incremental development tasks and bug fixes? >>> >>> Do you have any suggestions for a JIRA Workflow? If you already do not >>> have the right privileges on airavata jira, we can req >>> >>> >>> On Mon, Apr 21, 2014 at 8:57 PM, Vivek Bhatia <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> re: community building and suggestions. I completely agree with the >>>> following indicated in Suresh's email. It is always a good idea to think >>>> through the bigger picture first and break down the work into smaller >>>> chunks and file JIRA's for it. This is a very common industry practice and >>>> will help us in several ways such as provide a high level structure for the >>>> JIRA's, help other contributors understand the bigger picture and pitch in >>>> into the effort, help us evaluate work/milestone for each feature etc., >>>> additionally could also help identify what our roadmap is so that we can >>>> publish that out to perspective community/users for Airavta. We might be >>>> doing this already and it might be a good idea to take another look at this >>>> to see where we need to put more emphasis on, which is what I think the >>>> objective of this effort/email is... >>>> >>>> 1) The current core developers should spend more time in described >>>> requirements and clearly scoped improvements to JIRA. As developers, we >>>> tend to enjoy writing in java than in english. But I feel, the time we take >>>> of our own coding and writing well defined requirements will boost the >>>> community building. >>>> 2) JIRA tasks - Currently the developers are adding issues on what they >>>> are working. This is undoubtedly helping to track commits to JIRA, but as a >>>> good development practice, we should add as many tasks as possible, and >>>> then when we start to work on an issue, we should assign it to ourselves >>>> and start coding. This way we know the active development areas ahead of >>>> time and community can if possible align. >>>> >>>> >>>> my 2 cents here... >>>> -Vivek >>>> >>>> >>>> >>>> On Fri, Apr 18, 2014 at 8:09 PM, Suresh Marru <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I want to revisit the community building thread from over two years >>>>> ago. Any concrete steps we can take now? >>>>> >>>>> Eran, thanks for sharing some of these concerns in a post-hangout >>>>> discussion today. Can you please share some of your suggestions on this >>>>> thread? >>>>> >>>>> Suresh >>>>> >>>>> >>>>> On Sun, Feb 5, 2012 at 11:39 AM, Suresh Marru <[email protected]>wrote: >>>>> >>>>>> Thanks Ross for initiating this important conversion and for Chri's >>>>>> suggestions on OODT. >>>>>> >>>>>> Good to see some new community requests recently, it will be nice to >>>>>> get some feedback as well. So please speak up, both good and back feedback >>>>>> will be equally recieved. We would like to know how we can help lower the >>>>>> barrier to use and contribute to Airavata. >>>>>> >>>>>> In addition to what Marlon already mentioned, I can see some >>>>>> improvements we can make. >>>>>> >>>>>> 1) The current core developers should spend more time in described >>>>>> requirements and clearly scoped improvements to JIRA. As developers, we >>>>>> tend to enjoy writing in java than in english. But I feel, the time we take >>>>>> of our own coding and writing well defined requirements will boost the >>>>>> community building. >>>>>> 2) JIRA tasks - Currently the developers are adding issues on what >>>>>> they are working. This is undoubtedly helping to track commits to JIRA, but >>>>>> as a good development practice, we should add as many tasks as possible, >>>>>> and then when we start to work on an issue, we should assign it to >>>>>> ourselves and start coding. This way we know the active development areas >>>>>> ahead of time and community can if possible align. >>>>>> 3) Add all the test cases to be improved to JIRA, yes one more JIRA >>>>>> suggestion, but I feel this is important. >>>>>> 4) Improve architecture diagrams, data models, schema documentation, >>>>>> E-R diagrams what ever makes community to understand the code better. >>>>>> 5) Improve usability. Invite HCI usability experts to criticize at >>>>>> same time give suggestions to improve. >>>>>> 6) Airavata primarly caters to Scientific use cases, but as we >>>>>> realize, its fully general purpose and useful in many facets of other >>>>>> application areas. We should actively synergize and engage with workflow, >>>>>> messaging system and hadoop related projects. >>>>>> 7) Start developing web interfaces/gadgets to Airavata back end >>>>>> services and actively work with projects like Rave. >>>>>> >>>>>> Couple of brainstorming ideas: >>>>>> * Should we actively participate in Google summer of code? this not >>>>>> only helps us to break down the tasks, it also makes us think the next 6+ >>>>>> months of roadmap. If we are lucky, we might get good code contributions >>>>>> too. Ross, Chris, Any directions on how to proceed on this? >>>>>> * Invite Airavata to be used for capstone projects in programming and >>>>>> HCI courses? Answering student questions will improve our FAQ's greatly and >>>>>> as above we might expand community to both faculty and students. >>>>>> * Reach out to technical writers to seek their help in improving >>>>>> documentation? >>>>>> * How to address Marlon's comment on making the community feel that >>>>>> they need not write code to be part of the project and be pro-actively >>>>>> contribute to its future directions? >>>>>> >>>>>> Any others? >>>>>> >>>>>> Thanks, >>>>>> Suresh >>>>>> >>>>>> On Jan 31, 2012, at 12:13 PM, Mattmann, Chris A (388J) wrote: >>>>>> >>>>>>> Hi Marlon, >>>>>>> >>>>>>> Both of these are great suggestions and yes we can immediately cite >>>>>> a synergy with OODT as well and some >>>>>>> pilot projects. Getting the conversation on list will be great for >>>>>> the other direct contacts, but it's something we >>>>>>> struggled with originally in OODT and something that can be worked >>>>>> through. >>>>>>> >>>>>>> Great suggestions. >>>>>>> >>>>>>> Cheers, >>>>>>> Chris >>>>>>> >>>>>>> On Jan 31, 2012, at 6:18 AM, Marlon Pierce wrote: >>>>>>> > We've been recruiting several groups to participate, and I expect > >>>>>> an increase in communications on the list from java > cyberinfrastructure > >>>>>> developers from Iowa State and University of Minnesota. We > also have met > >>>>>> with Chris Mattman and others from Apache OODT, which is doing > >>>>>> complementary things. We have discussed pilot projects with > OODT, so I > >>>>>> think this is something we can do immediately to broaden the > community. > > Two issues I have seen: 1) we tend to get contacted directly by > >>>>>> collaborators instead of through the dev list, so we need to > encourage (or > >>>>>> insist) that more traffic goes on airavata-dev; and 2) we have many > >>>>>> collaborators who are not java developers but who have valuable > >>>>>> requirements, usage scenarios, feedback, complaints, etc that > also need to > >>>>>> go on the list. We need to make it clear to the second group > that there are > >>>>>> many ways to contribute besides submitting code patches. > > > Marlon > > > On 1/31/12 8:55 AM, Ross Gardler wrote: > >>>>>>>>> First off, I've been a little remiss in my duties as a > mentor here. > >>>>>>>>> Appologies for that and thanks to Chris for keeping things > moving. > >>>>>> I > >>>>>>>>> hope to find more time to spend on this project in the near > future. > >>>>>>>>> > >>>>>>>>> I would like to see the project members discussing how we can go > >>>>>> about > >>>>>>>>> building community diversity in the project. > >>>>>>>>> > >>>>>>>>> What simple actions can we take to raise awareness (over and > above > >>>>>> the > >>>>>>>>> lower barriers and make releases items in the board report)? > >>>>>>>>> > >>>>>>>>> I'm particularly interested in hearing from people who are > lurking > >>>>>>>>> here but not yet contributing. What is stopping you from > >>>>>> de-lurking? > >>>>>>>>> How can we help you take those first initial steps? > >>>>>>>>> > >>>>>>>>> For those active in the project how do we communicate the > value of > >>>>>>>>> Airavata to the rest of the world? Are there any often requested > >>>>>> items > >>>>>>>>> that people can work on as a first step into the project > community? > >>>>>>>>> > >>>>>>>>> Any other ideas? > >>>>>>>>> > >>>>>>>>> My goal is for us to come up with 3-5 concrete actions that > we can > >>>>>>>>> include in our next board report. > >>>>>>>>> > >>>>>>>>> Ross > >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> Chris Mattmann, Ph.D. >>>>>>> Senior Computer Scientist >>>>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>>>>>> Office: 171-266B, Mailstop: 171-246 >>>>>>> Email: [email protected] >>>>>>> WWW: http://sunset.usc.edu/~mattmann/ >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> Adjunct Assistant Professor, Computer Science Department >>>>>>> University of Southern California, Los Angeles, CA 90089 USA >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> >>>>>> >>>>>> >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> >>>>>> iQIcBAEBAgAGBQJPLrC8AAoJEHmz9P1hfdutJHUP/RnvhhB7m3N4p/FrSPh365Cu >>>>>> XRkN+aHF9bs2wEJohx0py/DJBD5Zpy1MiVisa9m0lBesnIJ1ZcEY2ox8lJOoMQQB >>>>>> HN0IMyeo9/miNFWGAqpBdxIDsBSo4GhI76KQQhPt/ui0MVmQBP/FePGkFaqTS8JK >>>>>> sbDR+BYMv/nZcYxJpFfHdPepiETyXqw29RZUF3SWKeeyDyLWiix23qE3KLiCIFlF >>>>>> kIdiWgNUq/5p6WaOkWuLWhh90tuKMbYVgaA02XbvqoI4ovrxWcSDsSxoaYos8T/1 >>>>>> OuubfJqRHgUXP1bMkFifYIYjQxMDN8hg0GAsD/wBy/CWxIHX+UBUc4C8+PjWHmnW >>>>>> 8i87bDnVELNNX9gX/GRGkeJQLaW7gUVkj2QX1SVc7SDgfylwWY2SQoNQfqrAjVEg >>>>>> Y32pDGsX42c2MO4GomJlcIMKtuk4FB5vInVGDFezLxdVoVPby6wwoh7BN6+poVAy >>>>>> ICnn0+bbjrQEfrM7yGyQDSjkfCnO2yWqds7pxxkwrWnFtGrUtsHFwM7mzalF99UL >>>>>> u72KBJn2HgIZTMZVTpIm+sZYtWCCxriANw4QqsMOCiFouepM6ez+j+TlTH83OJt3 >>>>>> DOc2HGKZWk4zfYqFEw62N3MxWpsYFsXT/ekCgYS0GvjSuVUqn2I6Nyy0NtrQnSPF >>>>>> ZLjMp55uaMt9M05mhVVF >>>>>> =4S2Q >>>>>> -----END PGP SIGNATURE----- >>>>>> >>>>>> >>>>> >>>> >>> >> >
