airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Plan for community buidling
Date Thu, 24 Apr 2014 21:28:46 GMT
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 <vivb77@gmail.com> 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 <smarru@apache.org> 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 <vivb77@gmail.com> 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 <smarru@apache.org>
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
<smarru@apache.org>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: chris.a.mattmann@nasa.gov
>>>>>>> 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-----
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



Mime
View raw message