Hi Vivek, These descriptions and example help a lot. So we can put some of these into practice, do you mind documenting these on the website/wiki and we vote them in as a guidelines and follow the practices? For instance the Rave project tried to employ similar guidelines early on [1].
Editing website will require to edit a markdown file and commit it back to SVN which will generate the html files. Instructions on these are at [2]. Alternatively, you can write them in a free flow format on Airavata Wiki [3]. Suresh [1] - http://rave.apache.org/issue-management.html [2] - http://airavata.apache.org/development/edit-cms-website.html [3] - https://cwiki.apache.org/confluence/display/AIRAVATA/ On Apr 22, 2014, at 5:21 PM, Vivek Bhatia <[email protected]> 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: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> 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 > >>> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG/MacGPG2 v2.0.16 (Darwin) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> iQEcBAEBAgAGBQJPJ/gqAAoJEEfVXEODPFIDHZAH/i6Zna9sHcis0GLEfTfotrzO > >> l2feAQMbG2I6IO/BOxM8lXtVPbjJGE7DhiFuskbjaommDl+v5Y83UP1lPUTkUIZy > >> 1qVCSlIY/7R0ey9ogYA4Yq4rOM7vC+udGlXM5c3Hob/uboctT5io573jx7nGBlqw > >> V857RAgbbJdXBVecr25FdEh0jU+It7oJGksERBJnH01EJEvQFof9/1GeuGmnJou4 > >> rd+LZJZNIhjXa1ZL/uR9BP7kPkMpk4dKVW6xq5d1pg2gJzU9/RE75DYY8r+fsRum > >> fUc37om165goIqSHjgq5kRfQdIAHliMwyH/cpp5yjd7a68hASkg5evHo2WxX+l8= > >> =6TAH > >> -----END PGP SIGNATURE----- > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 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----- > > > > > >
