On 5/2/11 2:50 PM, "Scott Wilson" <[email protected]> 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." <[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 >>> >>> >> >
