Update for 1/19 (first meeting)

[Audrey Eschright]

Today several of us met during the Code Sprint gathering at CubeSpace to talk and work on the calendar.

Participants: Audrey Eschright, Selena Deckelmann, Igal Koshevoy, Reid Biels, Paige Saez, Daniel Etra, Anselm Hook, and Bill Burcham.

We spent the first part of our gathering discussing our goals for the project. We focused on our reasons for creating a new calendar system, and the user communities we intend for this to serve. We determined that many existing calendar services have barriers to entry such as required registration that limit usage in our community. Current calendars can also lack the quality of details we would like to provide. We felt that creating a model for aggregating events around a specific interest area is important, and something that existing calendars only partially succeed at.

We also talked about the different types of groups and cultures within our community, loosely labeling them as business, new media, open source, and a fourth group that we called the X-factor or newbies: people who don't know they're part of our community until they see what kinds of events and groups are out there. Not requiring users to register an account with yet another centralized system seems important to serving many of these groups, since the existing tools they use reflect a range of preferences for connecting online.

We then split into pairs/small groups to work on specific tasks. Results:

* The existing group websites we examined can be imported much more easily with the addition of hCalendar markup for the event details. Selena and Daniel created documentation that we can share with event organizers (http://groups.google.com/group/pdx-tech-calendar/web/example-hcal-markup). We discussed the possibility of using a hCalendar generator to provide ready-made HTML to paste into websites and blogs.

* A next step for encouraging hCalendar usage will be to contact individual groups who aren't using a standardized calendar format, and tell them about our project.

* Paige created a sample email template that can be used to structure event information, for organizers to cc to our system when they send out event announcements. Email seems to be the one tool everyone uses, and this would help with our goal of accessibility.

* Igal and I set up a new Rails application, and added it to a group repository at http://code.google.com/p/calagator/. The application now has a bare bones structure for adding and viewing events. We also decided that event venues were important attributes, and that combining information on venues across events would be highly useful, so users can now add and update venue information as well. We're using a temporary view scaffolding system to allow us to add and edit information in the database. We'll develop a more polished interface as we continue.

* In order to begin pulling sample data from websites, Igal and Reid are creating an hCalendar event importer. This can also be used as a model for adding other calendar formats to the system.

* Igal is going to set up our calendar program on a server where people will be able to try it out. Getting feedback early and often will be important to ensuring we're meeting the needs of our users.

* Selena set up a new blog at http://calagator.wordpress.com/ to help us connect with the local tech community as we continue working on this.

Thanks everyone who came and participated today, and thank you also to everyone who has contributed to the discussion online. The diagrams and resources on the pdx-tech-calendar website were very helpful as we began work.

We'll be meeting again in two weeks, on February 2nd, for another round. Please feel welcome to attend whether or not you program or write HTML. We worked on many things that everyone can help with, including brainstorming, researching, and planning. Or if you have other skills you'd like to contribute, but don't know how to get started, email the list and we'll help.

--

Audrey Eschright

lifeofaudrey.com

[Igal Koshevoy]

Thanks go out to all those that showed up yesterday for the Code Sprint,
we got a lot done. All the opinions, documents and resources posted by
folks that weren't able to come were very useful and we spent a lot of
time discussing these. Extra thanks go out to Audrey for organizing this
and to Reid for staying up with me till they kicked us out at closing time.

The first draft of the application is available at http://calagator.org/

This barebones application:
- Lets you import events from hCal (e.g., point it at an Upcoming event)
- Lets you search/view/add/edit/delete events using a form
- Lets you search/view/add/edit/delete venues and assign them to events

For example, I've manually added an entry for the Code Sprint and
imported the Upcoming event for Ignite Portland 2.

The application isn't currently a masterpiece of design, usability or
functionality, but rather the first of many steps. It provides a minimum
amount of features and infrastructure so that we can incrementally
improve it as we work towards greater goals.

A lot of the work that's gone into this isn't visible through the
website though:

- A parser abstraction system that lets us easily add drivers that can
read more calendaring formats without having to rewrite our existing code.

- A new WordPress blog I setup at http://blog.calagator.org/ that needs
to be populated. I've given admin rights to Audrey and Selena. The
advantage of having this run on our server is that we can set the URL
and have full control over how it works as opposed to the one hosted off
WordPress.com.

- A password-protected web-based application administration system that
makes it easy to start, stop, restart, deploy and rollback the
application at http://calagator.org/ from a browser. This tool has its
own logins which can be given away more liberally than SSH accounts into
the production system. I've given Audrey rights to create additional
accounts. I made this as a stand-alone Ramaze application, so it can
manipulate the Rails app running calagator.org without being dependent
on any its code, thus making it possible to rollback a broken version of
the site.

- An AutomateIt recipe that automatically sets up the entire
calagator.org server. The recipe is run against a freshly-installed
Ubuntu server and does everything else, like setting up the OS, creating
UNIX users, installing dependencies, checking out the application,
managing the mongrel cluster, creating nginx proxies, setting up
Wordpress, etc. This lets me easily build and maintain a staging server
and reduce surprises by only deploying well-tested changes into
production. This automation will also help us more easily expand, adapt
and migrate the system in the future.

Anyway, I think we have most of the infrastructure in place that will
give us a stable platform and let us focus on adding new features that
people can see.

Cheers!

-igal

PS: I've also registered calagator.com and calagator.net, and rewrite
any requests that come in through these domains to the .org site.

[Daniel Johnson]

> The first draft of the application is available at http://calagator.org/

Will it be able to aggregate for other communities besides the tech
community. I know I am involved with other groups that could really
use similar tech.

--
teknotus
Take Notice

[Igal Koshevoy]

Daniel Johnson wrote:
> Will it be able to aggregate for other communities besides the tech
> community. I know I am involved with other groups that could really
> use similar tech.

Many of those present yesterday were excited at the long-term prospect
of being able to build something general enough that it can host
multiple kinds of communities on the same system, and be flexible enough
so that others could adapt it to their needs and host it themselves.

The beauty of this open source development model is that the
deliverables are whatever people find important enough to contribute. So
the way it looks, how easy it is to use, how well it meets people's
needs, how sophisticated its features get ... all these are dependent on
who can make time to work on this. If those other groups can get
involved, we'd be glad if they can join us so those features can be
implemented sooner.

-igal

[DanielEtra]

Excellent work all! It's great to see something up and running.
Because I am new to this, how do you all want to track bugs/issues?

It looks like importing does not automatically add the venue, at least
when I just tried. Also, when importing from eventful, which appears
to also use hcal, the link is broken.

Again, great to see something up and running!
-Daniel

On Jan 20, 7:24 pm, Igal Koshevoy <i...@pragmaticraft.com> wrote:
> Thanks go out to all those that showed up yesterday for the Code Sprint,
> we got a lot done. All the opinions, documents and resources posted by
> folks that weren't able to come were very useful and we spent a lot of
> time discussing these. Extra thanks go out to Audrey for organizing this
> and to Reid for staying up with me till they kicked us out at closing time.
>

> The first draft of the application is available athttp://calagator.org/

>
> This barebones application:
> - Lets you import events from hCal (e.g., point it at an Upcoming event)
> - Lets you search/view/add/edit/delete events using a form
> - Lets you search/view/add/edit/delete venues and assign them to events
>
> For example, I've manually added an entry for the Code Sprint and
> imported the Upcoming event for Ignite Portland 2.
>
> The application isn't currently a masterpiece of design, usability or
> functionality, but rather the first of many steps. It provides a minimum
> amount of features and infrastructure so that we can incrementally
> improve it as we work towards greater goals.
>
> A lot of the work that's gone into this isn't visible through the
> website though:
>
> - A parser abstraction system that lets us easily add drivers that can
> read more calendaring formats without having to rewrite our existing code.
>

> - A new WordPress blog I setup athttp://blog.calagator.org/that needs

> to be populated. I've given admin rights to Audrey and Selena. The
> advantage of having this run on our server is that we can set the URL
> and have full control over how it works as opposed to the one hosted off
> WordPress.com.
>
> - A password-protected web-based application administration system that
> makes it easy to start, stop, restart, deploy and rollback the

> application athttp://calagator.org/from a browser. This tool has its

[Anselm Hook]

Can I recommend redmine if googlecode does not suffice for issue tracking?

The latest rev of redmine is finally better than trac...

 - a

> PS: I've also registered calagator.com and calagator.net , and rewrite

[Audrey Eschright]

Google Code has a built-in issue tracker that we can try for now: http://code.google.com/p/calagator/issues/list

If it doesn't allow people to add bugs without being a project member, that's a problem, though. Would someone besides Igal go to that link and try to add a bug?

Otherwise, Redmine seems worth checking out. We'll need to install it somewhere if we want to try it.

--

Audrey Eschright

lifeofaudrey.com

[Anselm Hook]

I added one as a test - 'Show a Calendar'....

 - a

[Audrey Eschright]

On Jan 21, 2008, at 3:16 PM, Anselm Hook wrote:

> I added one as a test - 'Show a Calendar'....

Perfect, thanks. Let's stick with the Google code issues tracker
until there's a reason to move. I think it'll be simpler to have the
code and bugs and feature requests all in one place.

Audrey

[Igal Koshevoy]

On 1/21/08, DanielEtra <etrad...@gmail.com> wrote:

Because I am new to this, how do you all want to track bugs/issues?

I added a link to the bug tracker on the application's menu bar and added these requests to it.
 

It looks like importing does not automatically add the venue, at least
when I just tried.

Correct, we haven't implemented that yet, but that should probably be something we do in the next session, along with basic duplicate squashing so that it realizes that venue or event is already present and doesn't need to be recreated.

  Also, when importing from eventful, which appears
to also use hcal, the link is broken.

Thanks for the report. I've added a defect to the tracker and added some details. The Eventful variant of hCalendar seems different than Upcoming's. Lovely.

-igal

[Joe Cohen]

Belated thanks to Audrey, Selena, Igal, Reid, Paige, Daniel, Anselm,
Bill and everyone else involved in the 1/19 Codesprint and getting
Calagator up. It's great to see the progress on this.

[Joe Cohen]

On Jan 21, 3:38 pm, "Igal Koshevoy" <i...@pragmaticraft.com> wrote:
> On 1/21/08, DanielEtra <etradan...@gmail.com> wrote:
...

> > It looks like importing does not automatically add the venue, at least
> > when I just tried.
>
> Correct, we haven't implemented that yet, but that should probably be
> something we do in the next session, along with basic duplicate squashing so
> that it realizes that venue or event is already present and doesn't need to
> be recreated.

> -igal

Random issues (probably long-term) related to duplicate (event)
squashing.
Some events are sponsored by multiple organizations, and thus appear
on multiple non-aggregated calendars.
And then there are aggregated calendars.
Organizations change the description, date, time, or venue, so the
community calendar should (eventually) be smart enough to update the
event instead of rejecting the information. It's also desirable to
recognize -- for events that appear in multiple calendars -- which
calendar is authoritative.
Duplicates can also potentially be created manaually.

[Igal Koshevoy]

On Jan 26, 4:25 pm, Joe Cohen <jdco...@stoel.com> wrote:
> Random issues (probably long-term) related to duplicate (event)
> squashing.
> Some events are sponsored by multiple organizations, and thus appear
> on multiple non-aggregated calendars.
> And then there are aggregated calendars.
> Organizations change the description, date, time, or venue, so the
> community calendar should (eventually) be smart enough to update the
> event instead of rejecting the information. It's also desirable to
> recognize -- for events that appear in multiple calendars -- which
> calendar is authoritative.
> Duplicates can also potentially be created manaually.

Good points. Duplicates will get progressively more annoying as we
aggregate more data. From your description, I can see at least three
kinds of duplication:
(1) Unnecessary duplicates: If the same record was imported multiple
times, there ought to be only be one in the database. However, how do
we algorithmically recognize that a record is a duplicate of another
and should be discarded, especially if they're not identical? E.g.,
the two records are basically the same, except one title starts with
the word "MEETING: ", while the other just has the title's contents.
(2) Meaningful variations: Different records for an event were created
for different audiences and there's a legitimate need to keep
multiple variations of a single event's record. If so, how do we link
these variations together and let users choose between them?
(3) Updated values: Event information was updated and the database
ought to contain the current value. If so, how can the system know
which version is authoritative? Should the system try to guess? Should
it trust certain people or resources implicitly? And if so, who
determines which ones it trusts?

Creating algorithms to automatically deal with duplicates will be very
difficult. I believe that for a long time we'll be heavily dependent
on the goodwill of people importing events and those acting as
"gardeners" to keep the database clean, and therefore should
eventually provide tools to make good housekeeping as easy as
possible. I believe that for the foreseeable future the operational
model for this system will be more like that used to manage changes
made to a wiki.

-igal