<html><body>
<p><tt><font size="2">Sean Dague <sean@dague.net> wrote on 12/19/2013 05:09:16 AM:<br>
<br>
> From: Sean Dague <sean@dague.net></font></tt><br>
<tt><font size="2">> To: Thierry Carrez <thierry@openstack.org>, openstack-<br>
> infra@lists.openstack.org, </font></tt><br>
<tt><font size="2">> Date: 12/19/2013 05:10 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [OpenStack-Infra] Week-end project</font></tt><br>
<tt><font size="2">> <br>
> On 12/19/2013 05:58 AM, Thierry Carrez wrote:<br>
> > Sean Dague wrote:<br>
> >> I think there are 2 approaches that I see being fruitful, depending on<br>
> >> the kind of problem the team is going after.<br>
> >><br>
> >> 1) the yaml -> ical converter.<br>
> >><br>
> >> Bulk of invention is going to be on the converter, especially<br>
> >> translating into ical recurrance rules. Also will probably want / need<br>
> >> to build an HTML UI for the end result so people can actually see it on<br>
> >> a webpage as well.<br>
> >><br>
> >> 2) drupal + calendar + workflow<br>
> >><br>
> >> I was actually thinking about what ttx said about no tool existing out<br>
> >> there to be able to take calendar updates into an approval queue. I<br>
> >> think you could actually build that pretty easily with drupal base site<br>
> >> (logins connected to lp openid) + calendar modules + workflow module<br>
> >> (that allows for approval queues on changes).<br>
> >><br>
> >> Different set of things to learn (more on the drupal side), however the<br>
> >> advantages would be that a lot of the UI and ical bits would be handled<br>
> >> already.<br>
> > <br>
> > So.. approach 2 would definitely be more friendly for non-devs, but what<br>
> > I like about option 1 (in addition to its lack of specific<br>
> > infrastructure setup) is that you can check the proposed change for<br>
> > future conflicts before it is even reviewed and at merge time, using the<br>
> > same check/gate mechanisms we have for everything else. It sounds a lot<br>
> > more difficult to set up such automated verification in the drupal case,<br>
> > so that would push the conflict validation onto the human reviewing the<br>
> > change...<br>
> <br>
> That's definitely true. There would be a visual way to review, which<br>
> would be helpful.<br>
> <br>
> Anyway, I'd let the team doing the implementation figure out which set<br>
> of problems they wanted to solve. Both would be massive improvements<br>
> from where we currently stand.<br>
> <br>
> In my own nirvana I want a site I can go to, log in, tell it which<br>
> meetings I care about, and it builds me a custom ical feed that I can<br>
> link into my google calendar, and I'm done. Bonus if we actually got<br>
> people updating agendas in there. It feels like we could get there if we<br>
> started with a web stack that understood calendaring already. It's a ton<br>
> of work to get there from scratch. I've done calendaring up from scratch<br>
> before - <a href="https://github.com/sdague/inviter">https://github.com/sdague/inviter</a> - it's all doable. It's just<br>
> way more than a weekend project, and way more about dealing with the<br>
> craziness of ical itself.<br>
> <br>
</font></tt><br>
<tt><font size="2">I am not very familiar with Drupal, but from what it sounds like, it would do most</font></tt><br>
<tt><font size="2">of the ical conversion itself after having the users input event data and it passing</font></tt><br>
<tt><font size="2">through the approval workflow queue. I think I have a better idea of how to make the</font></tt><br>
<tt><font size="2">YAML file to iCal and viewable web page idea work, and would be able to offer</font></tt><br>
<tt><font size="2">better mentoring/knowledge support in that area.</font></tt><br>
<br>
<tt><font size="2">Regardless of the approach, we plan to have a team of 4 to 5 for a whole semester</font></tt><br>
<tt><font size="2">that will be working in an agile type process. A first goal could be to prototype</font></tt><br>
<tt><font size="2">something up for each approach and see what works best or is more achievable in the time</font></tt><br>
<tt><font size="2">frame. We (myself and a few other IBM devs) plan to do most of the</font></tt><br>
<tt><font size="2">mentoring/coaching/hand-holding for the duration of the project, with hopes they will</font></tt><br>
<tt><font size="2">be joining the ML and IRC discussions shortly after the project start.</font></tt><br>
<br>
<font size="2" face="sans-serif">Mathew Odden, Software Developer<br>
IBM STG OpenStack Development</font><br>
<tt><font size="2"><br>
</font></tt></body></html>