Latest revision as of 16:00, 25 January 2010

This page describes the specifications and implementation of NoiseCal, a calendaring solution that adheres to Noisebridge's practices and principles.

Folks[edit]

Specifications[edit]

Mailing List Threads[edit]

Requirements[edit]

Publicly editable
Unregistered editable
Revert edits
Publicly linkable
Has the usual variety of calendar layouts (day, week, month, list)
Events have a time, duration, description, recurrence, location
Exports to iCalendar (RFC 5545)
Widget on the wiki homepage
Free, as in free speech and free beer
Hosted locally

Bonus points[edit]

Can use wiki logins or some other kind of identification in addition to anonymous
Events have a field for which room/area of NB
Calendars show which room/area of NB
open source or some other moral superiority
easy publishing to email (for nb-announce, for instance)
misc bells and whistles
RSS feed
Some kind of reputation system, likely usernames. Edits can be associated with usernames.
Tagging/Categorizing of events are useful so as to group similar events. There's a lot going on at NB! IE: "5MoF", "Conlang", "Not Happening on a Regular Basis", "Reoccuring"

Überbonus Point[edit]

Views based on tags. IE, view all room reservations for the next day/week/month on a calendar with the tag "Dark Room" or "Project Euler Group", or the word "foo" mentioned anywhere in the entry (this last one

might make searches expensive).

Printable tag views. IE, I can print out all the room reservations for "Dark Room" this week and put it on the door (which will instantly be made out of date when the first edit comes along, phoey). This feature also lets conferences at NB self-schedule and you have an instantly printable/viewable calendar.

Implementation[edit]

We are still at the brainstorming and exploring phase.

There is some code on github but it's expected to be in great flux.

Meeting Notes[edit]

2010-01-23 15:00[edit]

We will base our work on the Calendar MediaWiki extension by Kenyu73.
Replace PrefixSearch with a category search. (Fetch all events from Category:Event.)
Parsing
- We shall use a human-readable wiki-ish format.
  - Every section titled Event Details shall contain details of a NoiseCal event. The section shall contain a list of key-value pairs of the form: * Key: Value.
  - Keys and values are case-insensitive.
  - Valid keys, for now, are: "Description" (required), "When" (required), "Where", "Recurring", "Organizer". Values of "When" must be valid ISO8601 timestamps.
- We parse out the event on save, and add categories as a layman's index. (Does this make sense?)
- Add parsing for time.
- Add recurring events. (this needs more thought)
- Validate stuff (on ArticleSave). If you clicked save, but your NoiseCal-related edits do not validate, you will get a preview with an error message--as specific as possible. We could render events "in the wild" via ViewHook?.
- Let event description be wherever in the article (currently the first line of an event article is the description).
Multiple events per wikipage.
iCalendar (RFC 5545)
- iCalendar export
- Use ObjectCache for caching
- How does iCalendar deal with past events? Do iCalendar feeds always export the entire history of a calendar?
- We should have a way to restrict an iCalendar feed to the past n months and to the past m months in the future. Defaults should be n=1 and m=3.

@@ Line 1: / Line 1: @@
-This page describes the specifications and implementation of a '''NoisyCalendar''', a calendaring solution that adheres to Noisebridge's practices and principles.
+This page describes the specifications and implementation of '''NoiseCal''', a calendaring solution that adheres to Noisebridge's practices and principles.
 = Folks =
@@ Line 7: / Line 7: @@
 = Specifications =
+== Mailing List Threads ==
+* [https://www.noisebridge.net/pipermail/noisebridge-discuss/2010-January/thread.html#11661 NoiseBridge Calendar by Kelly, started on 2010-Jan-19]
+* [https://www.noisebridge.net/pipermail/noisebridge-discuss/2010-January/thread.html#11785 NoisyCalendary by Ian Atha, started on 2010-Jan-23]
 == Requirements ==
 * Publicly editable
@@ Line 29: / Line 33: @@
 * Some kind of reputation system, likely usernames. Edits can be associated with usernames.
 * Tagging/Categorizing of events are useful so as to group similar events. There's a lot going on at NB! IE: "5MoF", "Conlang", "Not Happening on a Regular Basis", "Reoccuring"
+== Überbonus Point ==
+* Views based on tags. IE, view all room reservations for the next day/week/month on a calendar with the tag "Dark Room" or "Project Euler Group", or the word "foo" mentioned anywhere in the entry (this last one
+might make searches expensive).
+* Printable tag views. IE, I can print out all the room reservations for "Dark Room" this week and put it on the door (which will instantly be made out of date when the first edit comes along, phoey). This feature also lets conferences at NB self-schedule and you have an instantly printable/viewable calendar.
 = Implementation =
-We are still at the brainstorming phase
+We are still at the brainstorming and exploring phase.
+There is some code on [http://github.com/ github] but it's expected to be in great flux.
+* [http://github.com/thatha/noisecal thatha's repo]
+* [http://github.com/radii/noisecal radii's repo]
-= Meetings =
+= Meeting Notes =
 == 2010-01-23 15:00 ==
-* replace prefixsearch with cateogry->getMembers
+* We will base our work on the [http://www.mediawiki.org/wiki/Extension:Calendar_(Kenyu73) Calendar MediaWiki extension by Kenyu73].
+* Replace PrefixSearch with a category search. (Fetch all events from Category:Event.)
 * Parsing
-** add parsing for time
+** We shall use a human-readable wiki-ish format.
-** validate stuff (on ArticleSave or on every ViewHook). you could get a preview, even if you clicked save, if your edit is invalid. ViewHook?
+*** Every section titled '''Event Details''' shall contain details of a NoiseCal event. The section shall contain a list of key-value pairs of the form: <code>* Key: Value</code>.
-** let event description be wherever in the article
+*** Keys and values are case-insensitive.
-* iCalendar
+*** Valid keys, for now, are: "Description" (required), "When" (required), "Where", "Recurring", "Organizer". Values of "When" must be valid ISO8601 timestamps.
+** We parse out the event on save, and add categories as a layman's index. (Does this make sense?)
+** Add parsing for time.
+** Add recurring events. (this needs more thought)
+** Validate stuff (on ArticleSave). If you clicked save, but your NoiseCal-related edits do not validate, you will get a preview with an error message--as specific as possible. We could render events "in the wild" via ViewHook?.
+** Let event description be wherever in the article (currently the first line of an event article is the description).
+* Multiple events per wikipage.
+* iCalendar (RFC 5545)
 ** iCalendar export
-** use objectcache for caching
+** Use ObjectCache for caching
-* we shall use a human-readable wikiformat of the format:
+** How does iCalendar deal with past events? Do iCalendar feeds always export the entire history of a calendar?
-<nowiki>
+** We should have a way to restrict an iCalendar feed to the past <code>n</code> months and to the past <code>m</code> months in the future. Defaults should be <code>n=1</code> and <code>m=3</code>.
-= Event Details = (any heading level is acceptable)
-* Key: Value
-</nowiki>
-Valid keys, for now, are: "Description" (not optional), "When" (not optional), "Where", "Recurring", "Organizer". Values of "When" must be valid ISO8601 timestamps. Everything is case insensitive (both keys and values where applicable).
-We parse out the event on save, and add categories as a layman's index.
-How does iCalendar deal with past events? Or?
-a way to only get the x past months of events. default to one month.

NoiseCal: Difference between revisions