On 2 May 2011, at 17:26, Franklin, Matthew B. wrote:

> I have created a few Epics that I think encompass most of the very
> high-level features from the proposal that we would like to see for a
> first release.  I propose the following structure for managing our issues
> in JIRA:
> 
> 1) Highest level feature definitions are Epics (like OpenSocial container
> compliance)
> 2) Lower-level features are created as Stories and linked to the
> appropriate Epic (Like Render OpenSocial Gadgets on Page)
> 3) Anything required to make the Story go (persistence, model definition,
> services, etc) are defined as subtasks of the Story

I think its a good approach, though my preference would be to make the 
epics/stories less implementation-specific, as in "render rave widgets in a 
page or region" rather than "render opensocial gadgets on page". The 
OS/shindig-specific stuff is more in the nature of a technical task IMO.

> 
> I would also like to suggest that we begin using the Stories/Sub-tasks to
> track all work being done.  You can reference the JIRA # in the commit so
> that it will auto-tie to the issue.  In my mind, this looks something like
> identifying a story, or task, that you want to work on; creating it if it
> does not exist in JIRA; assigning it to yourself and letting the list know
> what you plan on doing; assume lazy consensus and do the work;  commit
> with the JIRA # and finally letting the list know that you are done.
> 
> Thoughts?

+1 its really useful to be able to see the commits related to a Jira issue

S

> 
> On 5/2/11 8:43 AM, "Franklin, Matthew B." <[email protected]> wrote:
> 
>> On 5/1/11 12:27 PM, "Ross Gardler" <[email protected]> wrote:
>> 
>>> Just a quick comment about "module being assigned to one team" and your
>>> acknowledgement of the problems such an approach can bring. I'd suggest
>>> that "assignment" is the wrong way around. It forces someone to tell
>>> someone else what to do - that's not how an ASF project works. Everyone
>>> owns everything in an ASF project and everyone dives in where they feel
>>> most able. 
>>> 
>>> I understand your concern about not knowing where to contribute. This can
>>> indeed be a problem, especially for new communities or new members of a
>>> community.  However, I'd say that you just indicated where you can
>>> contribute healthily.
>>> 
>>> Perhaps getting these features into the issues tracker so we can start to
>>> develop a roadmap. The we can encourage folk to contribute initial
>>> proposals or code as appropriate.
>> 
>> The feature lists from the proposal are very high-level and contain a lot
>> of implicit features within them.  Assuming lazy consensus, I will put a
>> few of the listed features in as Epics into JIRA and break down the one I
>> am currently working on into Stories.
>> 
>>> 
>>> Thanks for starting this constructive discussion - that's how a healthy
>>> ASF project works - it's not really all that had ;-)
>>> 
>>> Ross
>>> 
>>> Sent from my mobile device.
>>> 
>>> On 1 May 2011, at 15:20, Raminderjeet Singh <[email protected]>
>>> wrote:
>>> 
>>>> Hi All 
>>>> 
>>>> As we have nice framework working and have done with most of the ground
>>>> work. I think its a good idea to visit the feature list  from Rave
>>>> proposal [1] and have small discussion on team/individual contributions.
>>>> We can elaborate little bit more on these items (may be just from our
>>>> previous discussions) and have some key modules figured out. I
>>>> understand the impacts of module being assigned to one team but we can
>>>> come up with some thing better. I bought this as its my 1st apache
>>>> project and its difficult for me to decide where to start and
>>>> contribute. 
>>>> 
>>>> Core Features
>>>> 
>>>> Advanced OpenSocial compliance and optional features support
>>>> OpenSocial persistence and SPI implementation
>>>> Self-service application administration including security, gadget
>>>> management and page templates
>>>> User and group management with full privacy model
>>>> Gadget repository with life-cycle management (install/update/remove)
>>>> and extended meta data (categories, comments, ratings, etc.)
>>>> Dynamic and highly customizable front-end engine (skins, pages, tabs,
>>>> layouts, navigation)
>>>> Full OAuth support
>>>> Support for security restrictions on both Gadgets and page/tag/layout
>>>> customizations
>>>> Set of common and general purpose Gadgets to be usable out-of-the-box
>>>> Support for inter-gadget messaging with examples
>>>> Extensible Features
>>>> 
>>>> Pluggable persistence
>>>> Pluggable security model with example modules for authentication and
>>>> authorization
>>>> Support for OpenSocial extensions not (yet) defined in the
>>>> specification
>>>> Support for other (non-standard, yet) pluggable container services and
>>>> extensions
>>>> [1] http://wiki.apache.org/incubator/RaveProposal
>>>> 
>>>> Thank
>>>> Raminder
>> 
>> 
> 

Reply via email to