Open Stack

Sean Dague <sean at dague.net> wrote on 12/19/2013 05:09:16 AM:

> From: Sean Dague <sean at dague.net>
> To: Thierry Carrez <thierry at openstack.org>, openstack-
> infra at lists.openstack.org,
> Date: 12/19/2013 05:10 AM
> Subject: Re: [OpenStack-Infra] Week-end project
>
> On 12/19/2013 05:58 AM, Thierry Carrez wrote:
> > Sean Dague wrote:
> >> I think there are 2 approaches that I see being fruitful, depending on
> >> the kind of problem the team is going after.
> >>
> >> 1) the yaml -> ical converter.
> >>
> >> Bulk of invention is going to be on the converter, especially
> >> translating into ical recurrance rules. Also will probably want / need
> >> to build an HTML UI for the end result so people can actually see it
on
> >> a webpage as well.
> >>
> >> 2) drupal + calendar + workflow
> >>
> >> I was actually thinking about what ttx said about no tool existing out
> >> there to be able to take calendar updates into an approval queue. I
> >> think you could actually build that pretty easily with drupal base
site
> >> (logins connected to lp openid) + calendar modules + workflow module
> >> (that allows for approval queues on changes).
> >>
> >> Different set of things to learn (more on the drupal side), however
the
> >> advantages would be that a lot of the UI and ical bits would be
handled
> >> already.
> >
> > So.. approach 2 would definitely be more friendly for non-devs, but
what
> > I like about option 1 (in addition to its lack of specific
> > infrastructure setup) is that you can check the proposed change for
> > future conflicts before it is even reviewed and at merge time, using
the
> > same check/gate mechanisms we have for everything else. It sounds a lot
> > more difficult to set up such automated verification in the drupal
case,
> > so that would push the conflict validation onto the human reviewing the
> > change...
>
> That's definitely true. There would be a visual way to review, which
> would be helpful.
>
> Anyway, I'd let the team doing the implementation figure out which set
> of problems they wanted to solve. Both would be massive improvements
> from where we currently stand.
>
> In my own nirvana I want a site I can go to, log in, tell it which
> meetings I care about, and it builds me a custom ical feed that I can
> link into my google calendar, and I'm done. Bonus if we actually got
> people updating agendas in there. It feels like we could get there if we
> started with a web stack that understood calendaring already. It's a ton
> of work to get there from scratch. I've done calendaring up from scratch
> before - https://github.com/sdague/inviter - it's all doable. It's just
> way more than a weekend project, and way more about dealing with the
> craziness of ical itself.
>

I am not very familiar with Drupal, but from what it sounds like, it would
do most
of the ical conversion itself after having the users input event data and
it passing
through the approval workflow queue. I think I have a better idea of how to
make the
YAML file to iCal and viewable web page idea work, and would be able to
offer
better mentoring/knowledge support in that area.

Regardless of the approach, we plan to have a team of 4 to 5 for a whole
semester
that will be working in an agile type process. A first goal could be to
prototype
something up for each approach and see what works best or is more
achievable in the time
frame. We (myself and a few other IBM devs) plan to do most of the
mentoring/coaching/hand-holding for the duration of the project, with hopes
they will
be joining the ML and IRC discussions shortly after the project start.

Mathew Odden, Software Developer
IBM STG OpenStack Development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131220/a64dad70/attachment.html>