Proposed new Calendar-wiki structure
Joey Minta
calendar-wiki, I put together this basic structure that I'd like to put
forward for discussion. Every item in the following outline would be a
separate wiki-page. Additionally, I've fleshed out what the features
page might look like. However, there seemed to be some disagreement in
the meeting over their exact function, so perhaps people would like to
clarify their goals for these pages. I think this structure ought to
accommodate most of the existing pages, although there are a few
stragglers that I'm not sure where they may fit (Backwards
Compatibility, Timezones, Updating libical). Feedback welcome.
Calendar Wiki Structure
I. Mainly for end-users
A. Calendar FAQ - Frequently asked questions about Sunbird/Lightning
B. Latest Lightning release notes - Information about the latest
release of the calendar extension for Thunderbird.
C. Latest Sunbird release notes - Information about the latest
release of our standalone calendar client, Sunbird
D. How to contribute - testing, reporting bugs, giving feedback
E. Sunbird/Lightning roadmap - Where we're going
1. Links to past release notes
2. Links to in progress release notes
II. Mainly for developers/testers
A. Beginner's guide to hacking calendar/ - Information for someone
looking to get their feet wet in the mozilla codebase for the first time
B. Developer's Guide - A bird's eye view of the calendar codebase
C. Weekly meeting notes - Notes from past meetings held on IRC.
Also includes the schedule and agenda for the next meeting
C. Feature implementations - Proposals, descriptions, and
discussions regarding key features
1. iTIP/iMIP
2. Drag'n'Drop
3. Event Dialog
4. Attendees
5. CalDAV (or maybe just calendar providers?)
6. PDA Syncing
7. Performance/Speed
8. Modification architecture
9. UI Sync between Sunbird/Lightning
10. Diverse audiences - Accessibility, Localization,
Internationalization
D. Testing
1. Testing matrix
2. Available automated tests (none at this time)
*** *** ****
Each of the feature implementation pages would have the following basic
structure:
[Back to features]
This page is meant to be used by calendar developers. To add minor
comments/feedback, please use the [discussion page]. More extensive
discussion should be taken the [newsgroup].
==Basic overview==
This page covers features generally related to...
This is cool because...
Our eventual goal(s) for this feature include...
==Proposal pages==
*Link to related proposal page 1
*Link to related proposal page 2
==Related bugs==
*Link to bug 123456
*Link to bug 999999
Mortiz 'Morty' Strübe
> In light of today's meeting's discussion to reorganize the
> calendar-wiki, I put together this basic structure that I'd like to put
Is it also part of the concept to get spread information together? At
the moment there is some information at mofo, mozdev, wiki, devmo(?),
private pages. It would be really cool not to only set up all
information at one place but also take down the information at other
places and set up links to this one place.
Morty
Dan Mosedale
> In light of today's meeting's discussion to reorganize the
> calendar-wiki, I put together this basic structure that I'd like to put
> forward for discussion. Every item in the following outline would be a
> separate wiki-page. Additionally, I've fleshed out what the features
> page might look like. However, there seemed to be some disagreement in
> the meeting over their exact function, so perhaps people would like to
> clarify their goals for these pages. I think this structure ought to
> accommodate most of the existing pages, although there are a few
> stragglers that I'm not sure where they may fit (Backwards
> Compatibility, Timezones, Updating libical). Feedback welcome.
In general, I think this proposal looks excellent.
I'd argue that "Backwards compat" and "Timezones" are both features, and
we probably want a high-level "Administrative" section for stuff like
"Updating libical", "Release Process", etc.
> C. Feature implementations - Proposals, descriptions, and
> discussions regarding key features
> 1. iTIP/iMIP
> 2. Drag'n'Drop
> 3. Event Dialog
> 4. Attendees
> 5. CalDAV (or maybe just calendar providers?)
> 6. PDA Syncing
> 7. Performance/Speed
> 8. Modification architecture
> 9. UI Sync between Sunbird/Lightning
> 10. Diverse audiences - Accessibility, Localization,
> Internationalization
I bet the three things listed in (10) want to each have their own pages.
> Each of the feature implementation pages would have the following basic
> structure:
>
> [Back to features]
> This page is meant to be used by calendar developers. To add minor
> comments/feedback, please use the [discussion page]. More extensive
> discussion should be taken the [newsgroup].
>
> ==Basic overview==
> ==Proposal pages==
> ==Related bugs==
Maybe also a
== Design/Implementation status on the CVS trunk as of YYYY/MM/DD ==
section would be worthwhile in some (all?) feature pages as well.
Dan
Dan Mosedale
You're definitely right that we need to have a high-level discussion
about how our information is organized. In general, I like the idea of
keeping most information on wikis, as it seems to me that it makes it
more likely to that that info will be up-to-date or fixed when it's not.
If there is consensus around this, it would seem in particular to
suggest a shrinking role for mozilla.org.
As far as devmo vs. wiki.m.o, devmo tends to be a little more aimed at
"production" use and wiki.m.o tends to be more somewhat more of a
scratchpad. Maybe the "how to get involved" and "birds-eye-view" docs
along with interface documentation want to live on devmo, but also be
linked to from the scratchpad-like patches on wiki.m.o. Thoughts?
The biggest calendar content I'm aware of on mozdev that is the calendar
help stuff and the various associated extensions. What happens here
depends a lot on what Rod's thoughts are on the issue. I wouldn't be
averse to integrating the calendarhelp stuff more tightly into
.mozilla.org domains, if he's interested in that. At some level, this
also depends on what the bigger picture help story is for Thunderbird,
and how we think the best way is to share calendar help content between
Sunbird and Thunderbird/Lightning.
Dan
Joey Minta
> Joey Minta wrote:
> I'd argue that "Backwards compat" and "Timezones" are both features, and
> we probably want a high-level "Administrative" section for stuff like
> "Updating libical", "Release Process", etc.
>
>> C. Feature implementations - Proposals, descriptions, and
>> discussions regarding key features
>> 1. iTIP/iMIP
>> 2. Drag'n'Drop
>> 3. Event Dialog
>> 4. Attendees
>> 5. CalDAV (or maybe just calendar providers?)
>> 6. PDA Syncing
>> 7. Performance/Speed
>> 8. Modification architecture
>> 9. UI Sync between Sunbird/Lightning
>> 10. Diverse audiences - Accessibility, Localization,
>> Internationalization
>
> I bet the three things listed in (10) want to each have their own pages.
general headings, to avoid the mega-list that we have right now.
Unfortunately, we've already reached 14 (9+3 from #10+two mentioned
above), which means I'm failing at that so far. Do others think this is
a reasonable goal or will it just bury important things in tough to find
places?
>
>> Each of the feature implementation pages would have the following
>> basic structure:
>>
>> [Back to features]
>> This page is meant to be used by calendar developers. To add minor
>> comments/feedback, please use the [discussion page]. More extensive
>> discussion should be taken the [newsgroup].
>>
>> ==Basic overview==
>> ==Proposal pages==
>> ==Related bugs==
>
> Maybe also a
>
> == Design/Implementation status on the CVS trunk as of YYYY/MM/DD ==
>
> section would be worthwhile in some (all?) feature pages as well.
Yeah, although it'll be a bit difficult to keep people on the hook for
those.
-Joey
Dan Mosedale
> Dan Mosedale wrote:
>> Joey Minta wrote:
>>> 10. Diverse audiences - Accessibility, Localization,
>>> Internationalization
>>
>> I bet the three things listed in (10) want to each have their own pages.
> I'm trying as much as possible to combine some of these into more
> general headings, to avoid the mega-list that we have right now.
> Unfortunately, we've already reached 14 (9+3 from #10+two mentioned
> above), which means I'm failing at that so far. Do others think this is
> a reasonable goal or will it just bury important things in tough to find
> places?
I don't think we want to do a lot of hierarchical pages, as it will make
things harder to find. We could certainly organize it as multiple small
lists (eg UI, Architecture, Administrative, ...) all clustered together
in this part of this page.
>> Maybe also a
>>
>> == Design/Implementation status on the CVS trunk as of YYYY/MM/DD ==
>>
>> section would be worthwhile in some (all?) feature pages as well.
> Yeah, although it'll be a bit difficult to keep people on the hook for
> those.
Right, that's why I think the date is important, as least it'll help
readers figure out what the amount of bit-rot in that page is likely to be.
Dan