rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject Re: Feature List (from Proposal)
Date Mon, 02 May 2011 19:23:33 GMT
On 5/2/11 2:50 PM, "Scott Wilson" <scott.bradley.wilson@gmail.com> wrote:

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

My assumption was that we would have another Epic for each type of widget
that we want to render, since there is a lot of work involved in getting
each type up and running.  If you want to genericize the epic and make the
stories bigger, that¹s fine too.

>
>> 
>> 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." <mfranklin@mitre.org> wrote:
>> 
>>> On 5/1/11 12:27 PM, "Ross Gardler" <rgardler@apache.org> 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 <raminderjsingh@gmail.com>
>>>> 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
>>> 
>>> 
>> 
>


Mime
View raw message