EditAttachWiki Help
r20 - 26 Apr 2006 - 23:35:31 - PriscillaChungYou are here: OSAF >  Journal Web  >  ContributorNotes > JohnTownsendNotes > ScoobyZeroDotTwoFeatureRankingMatrix

Scooby 0.2 Feature Ranking Matrix

The basic idea here is to narrow down a list of features to a proposed feature set for Scooby 0.2 release.

Steps:

  1. Document all features considered to meet target users release in the matrix.
  2. Work with PPD to determine the Product Priority of each feature.
  3. Engineers respond with difficulty ratings and any dependencies between features. Recommendations are made for what's in/out for 0.2.
  4. Final rankings are determined (formula = (Product Priority * 10) + Engineering Difficulty))
  5. Team makes decisions based on final rankings for the proposed feature set.

Any open issues will be addressed on the Scooby development list.

Num Feature Dependencies Priority Eng Difficulty Ranking Bug# Plan Notes Reccomendation for 0.2
1 Account/Viewing/Creation: View User's Chandler Calendar on cosmo-demo Cosmo 0.3 on cosmo-demo P1 n/a     JohnTownsend - We are going to have scooby-demo as an experimental server for Scooby 0.1. BobbyRullo - this is not a feature for any release. this is a task for ops or something. JaredRhine - Cosmo-demo migration dependent on non-Scooby factors; stated goal is Cosmo 0.3 release + 6 weeks. QA has signoff on cosmo-demo moving to 0.3 because of Chandler 0.6/0.7-pre validation testing talk with Jared about this.
2 Account/Viewing/Creation: Make it a simple process for end-user to create account and login to Scooby Session   P3 Done for snarf     defer BobbyRullo - not sure what this means, but you now do this pretty easily in the bundle - mde created a nice sign up page for this. recommend: out
3 Account/Viewing/Creation: Specify a URL for cosmo, as opposed to separate properties for hostname, port, etc.   P2 s:1, c:0 21   towns BobbyRullo - This should not be a P1, because it doesn't affect end users in anyway, just makes setup for admins slightly easier. recommend: in
4 Navigation: Day view   P2 s:0, c:3 23     PriscillaChung - Bascially this view would be consistent to the 'all day view' in Chandler. Without implementing this feature there is no actual data lost. All the events on Chandler are still viewable in the week fiew. Based on the target user's release, a Scooby user could still use Scooby with this feature implimented. Based on a handful of user's feedback on when they use the 'All day view', I would recommend to work on the print feature in addition to the 'All day view'. recommend: out?
5 Navigation: Multiple Calendars - Show the display name instead of path name (no calendar overlay, but be able to switch between different calendars)   P1 s:2, c:2 12   bobby PriscillaChung - What happens when a user changes the name of a collection in Chandler? When the user syncs their Chandler calendar, and refreshes the Scooby web applicaton, the collection 'display name' in Scooby will display the same 'display name' in Chandler. It this possible? Or is there some kind of syncing issue with Cosmo an issue? recommend: in
6 Navigation: Basic mini calendar (will define in spec as to the basic functionality to meet target user)   P1 s:0, c:4 14   defer for 0.2 If there is a jump to date, mini cal. can come later.
P1 probably not for 0.2 		recommend: out
7 Navigation: Sidebar: should the user be able to view not only their calendar, but all the subscribed calendars once they are logged into Scooby (open issue) BobbyRullo - (depends on subscriptions to other peoples calendars in Scooby) P1 s:3(5+), c:5 15?   mde - have sent to the list
Main.PriscillaChung - was this sent out, I can't find it in the archives?? 		PriscillaChung - The question that needs to be addressed is if a user logs onto Scooby and should they automatically see all their collections on Scooby, or would then need to re-subscribe to each to each collection?
Main.MatthewEernisse - Are we sending to the list for feedback about the sidebar in general, or viewing subscribed calendars? Building the Sidebar itself is something we pretty much have to do. 		 
8 Managing calendars: Storing A Default Timezone   ??? s:2, c: 4 ?4   PC - have sent to the list.    
9 Managing calendars: Having the USER set the default Timezone from a list of TZ's   P1 s:2, c: 4 14   PC - have sent to the list.    
10 Managing Timezones: Having the SYSTEM guess what the default timezone should be based on IP address   ??? s:4 ?4   PC - have sent to the list.    
11 Managing Timezones: Being able to switch the current timezone 8, 9, 12 P1 s:0, c: 1?   PriscillaChung - Can we remove this feature from the list? PriscillaChung - This looks like a duplicate. It's covered by 8,9 & 12, not dependent.  
12 Managing Timezones Figuring out how to deal with timezones on the client side needs user preferences P1 s:2?, c: 5 15   PC - have sent to the list.    
13 Managing events: Viewing of recurring events (and knowing its recurring)   P1 s:1, c:2 12   mde not editable, just viewing data in either block or form (tdb)
 recommendation: in
14 Managing events: Special Chandler event types to display correctly in Scooby (@time, anytime events) (Open Issue)   P1 s:0, c:2 13   mde - have sent to the list MatthewEernisse - What does it mean to display? Are we talking the little lozenge shapes, or just showing the type in the detail form?
Main.PriscillaChung - Please review lozenge studies Mimi have sent to the design list 		Here are some studies I did based on Mimi's proposal of event lozenge.
15 Managing events: display of alarms (Open issue)   P1 s:0, c:? 1?   PC - have sent to list. BobbyRullo - perhaps we want to break out creation and display, as again, only viewing is a tenet for now. MatthewEernisse - People might get the impression from being able to see the alarm info that it will actually do something when they're in Scooby.  
16 Managing events: Creation or display of event status (confirmed, tenative, fyi)   P1 s:1, c:2 (2 days) 12   towns PriscillaChung - Please review lozenge studies Mimi have sent to the design list recommendation: in
17 Calendar canvas interactions: Time line on the left (Open Issue is now closed)   P1   1   *Not sending to the list* (PC) PriscillaChung - Although this was originally an open issue that needed to be sent to the list, the goals for current 'target user/dog foodable' release should currently display the timeline on the left. This feature my be revisited in future release and may have the user decide what is to be displayed under the preferences area.  
18 Calendar canvas interactions: Visual tweaks consistent with Chandler (i.e. Scooby Logo, consistent icon set, small aesthetics-tweaks - will break down in Bugzilla   P1 s:0, c: ?? 1   Priss to drive, mde to implement.
Design Swag: 5 solid days of work 		PriscillaChung - Propose
-layout of sidebar and event details (0.2)
-standardize buttons/style (0.2)
-style guide (can get started and build an html style guide/wiki) 		recommend: in
19 Calendar canvas interactions: Public calendar - Be able to display Read-only calendars, e.g. a public calendar for play rehearsals via a simple URL without the user having to have an account depends on ticket support? (Item #27) P1 (1.0)   1   send to list, future for now. JohnTownsend - public read only scooby calendar view, possibly a 1.0 feature? recommend: in (feature to get people using it)
20 Calendar canvas interactions: Reconcillation of the same event on multiple calendars (Open Issue)   P1   1   PC- may not need to send to the list as it is being resolved in the lozenge design. Please review lozenge studies Mimi have sent to the design list JohnTownsend- pris to do visuals and push to design list?
Main.PriscillaChung - Please review lozenge studies Mimi have sent to the design list 		 
21 Calendar canvas interactions: Setting timezone for the calendar (Open Issue)   P1   1   PC - have sent to the list. JohnTownsend - pris to do visuals and push to design list?  
22 Navigation: Jump to date   P2   2   mde JohnTownsend- mde: this is for target users, move to target release. MatthewEernisse - Is this 'in' for target-user or 0.2? recommend: in
23 Infrastructure: CalDAV4j: Figure out the real name of this project (even if its CalDAV4j)   P4   4   bobby JohnTownsend - Not critical recommend: in
24 Infrastructure: CalDAV4j: Separate CalDAVCalendarCollection? API into a DAO and Manager   P2 s:2, c:0 22   bobby   recommend: in
25 Infrastructure: CalDAV4j: Extend the Slide client WebDAV collection API so that it can return CalDAVCalendarCollections? and find calendar collections that are within it.   P2 s:2, c:0 22   bobby   recommend: in
26 Infrastructure: CalDAV4j: Add caching in various areas (cache Event UID --> Resouce Path, cache iCalendar resources with eTags)   P2 s:3, c:0 23   bobby   recommend: in
27 Infrastructure: CalDAV4j: Add Ticket Support   P4 s:4, c:0 44   bobby JohnTownsend - important if we are doing sharing through Scooby. recommend: in
28 Infrastructure: CalDAV4j: Free/busy reports   P4 s:4, c:0 44   bobby BobbyRullo - probably should be a P4 at least, since this isn't needed in Scooby till we doing Scheduling recommend: out
29 Infrastructure: CalDAV4j: Make sure previous work is caught up to the latest CalDAV spec   P2 s:2, c:0 22   bobby JohnTownsend - important to remain in sync with CalDAV recommend: in
30 Testing: Integrate JS unit tests into Maven build process.   P2 s:3 23     JohnTownsend - We need to do this soon. MatthewEernisse - Would like to see some automated testing of at the date.js utility functions at minimum. recommend: in
31 Testing: Write additional unit tests (especially for CalDAV4j and scooby <==> iCalendar conversion utils)   P2 s:2 22       recommend: in
32 Coding Standards: Have some sort of Coding standards for Java and JavaScript   P2 2 22   towns   recommend: in
33 Coding Standards: Organize JS files into folders to resemble packages in Java   P2 2 22   towns   recommend: in
34 Navigation: Month view   P3   3?   defer JohnTownsend - may not required for target user release. recommend: out
35 Managing Calendars: Publish/subscribe workflows - no dialogs to type in URLs (Open Issue)   P3 s:4, c:2 34   PC - send to list Viewing a person's calendar in ready only scooby mode.  
36 Managing Calendars: Import .ics files   P3 s:3, c:2 33   defer JohnTownsend - scooby is more about viewing your calendar for now, editing/exporting can be done from clients like chandler. recommend: out
37 Managing Calendars: Export .ics files   P3 s:3, c:2 33   defer JohnTownsend - scooby is more about viewing your calendar for now, editing/exporting can be done from clients like chandler. recommend: out
38 Managing Calendars: Setting timezones on events (Open Issue)   P3       PC - have sent to the list.    
39 Internationalization: Allow user to choose other languages from those installed   P3 s:1, c:1 (1 day) 31   bobby JohnTownsend - focus should be on infrastructure, could be a place to have contributors work on i18n. recommend: out for 0.2. (Work can start now)
40 Security: Implement finer grained security for RPC calls - right now only authenticated users can get in, but we maybe we want anonymous users to be able to do SOME webservices, like AUTH   P3 s:4 34   bobby   recommend: out for 0.2 release, but work can start now. (just not slated for 0.2)
41 CMP: How about a CMP client library for taking to Cosmo   P3 s:4     defer Wait for principle namespace support from Cosmo recommend: out
42 Out list: No calendar overlays (color, etc.)   P4       defer   recommend: out
43 Out list: Drag and drop events to add them to a different calendar   P4       defer   recommend: out
44 Basic User preferences and UI for editing them (password, name, timezone, language, etc.) Depends on CMP. P2 s:2, c:3 (4 days) 23   bobby   recommend: in
45 Infrastructure for skinning and UI templates   P2 s:3, c:3 (4 days) 23   mde MatthewEernisse - Needed infrastructure. recommend: out for 0.2 (Work can start now)
46 Overlapping events within the same calendar   P2 s:0, c:5+ (14 days) 25+   mde MatthewEernisse - critical to have a usable calendar. recommend: in
Notes

Feature Description - keep in mind that feature is used to describe an unit of work that would need to be accomplished in the upcoming release. For example, we could describe a feature as a package of Bugzilla bugs that we would like to address for the release and treat that as a "feature" for these purposes.

Dependencies - Note the numbers of other features that the current feature depends upon (e.g. 2, 3, 15)

Product Priorities are determined using the P1 through P5 ratings in DesignProcessTerminology.

Engineering Difficulty - A rough SWAG at the amount of time a feature would take to design, implement, test, and document. 1 usually means Easy, 5 means HUGE.

Open Issues

Editing * How much editing is really needed for Scooby for meet target users release? * If the event lives on multiple calendars, should users be able to remove events on other calendars when refreshed? Perhaps for target user release, we not trying to support a fully functional editing on Scooby. * Only concerned with read scenarios. Write scenarios don't need to work? * Reconciliation of the "same event" on "multiple calendars"? (Need clarification?)

Viewing your (Chandler) calendar on Scooby * Is Scooby intended to be a web version of Chandler � for now? * To view the User's (Chandler) calendar on Cosmo-demo. (Will the idea of OSAF as a 'service' need to be introduced for target user release?) * Would a user be able to view all the collections once logged on to Scooby or would the user be able to select the collections they want to have published to Scooby?

Timezones * Should users be able to change the default timezone on Scooby? If this release is only usable for read-only scenarios then this may not be needed as we're mostly focused on display issues? * Let the users set a default timezone * Be able to set the timezone on events

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r20 < r19 < r18 < r17 < r16 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.