[Ocs] Meeting Proposal: OCS Next Sprint Review

[Josef Spillner]

Hello,

:: Laszlo Papp Sonntag 04 März 2012
> Hence my proposal (I know it sounds a bit strange, but please bear with
> me): What about an IRC meeting at some weekend, preferrably a dedicated
> Saturday, either in the second half of March or the first half of
> April ? I would not personally like to postpone this happening too
> much (ie. months), if possible. Unfortunately, it does not work for me
> earlier because of the upcoming Plasma Active 3 Sprint and the
> post-activities of that event.

Thanks for the initiative! For me, any date except March 26-31 is good.

> My plans would be for this meeting, in a nutshell:
> 1) Get as many contributors as possible around this standard to build
> a nice community which can sustain itself later.

The community-building gruntwork includes a good web presence, including 
properly deprecating ghns.freedesktop.org, among others. It will also include 
a closer look at recently developed web initiatives, such as ".well-known" and 
so forth, to see how sites and services describe themselves and make 
themselves discoverable, and the already discussed module-specific overlaps 
with FOAF & friends (pun intended).

> 2) Obviously, review the points we made about a RESTful Standard at
> the previous Sprint :), and more importantly: get them written into a
> draft format on some public page.

Right. Modelling freaks wanted. Keep the specification generic, extensible, 
intuitive, non-ambiguous, focused, ...

> 3) Distribute standard editing tasks, due to the enumerated ideas, to
> the participants.

This sounds a bit like bugtracker work: To keep track of what parts need 
finishing when, and what parts are interesting but rather targeted for future 
revisions.

For example, I recently thought about the viability to describe all of a 
user's online assets. This has quite some potential, but would suck manpower 
from the rather urgent tasks of finishing v2.

We could also prioritise the parts. For instance, from my point of view, 
buildservice module is quite implementation-oriented and could develop into a 
more useful generic software publishing module for people without the need to 
"build" something, if given enough attention. The naming of the "friend" 
module is not suitable to build a business contact network, the "privatedata" 
could be rather "attributes" with private/public settings, etc.

> 4) Clearly define the strategy for trying to make client side
> implementation(s), like an add-on Qt5 module (which I, for instance,
> would love to deal with), python, php implementation and so forth.

Right. Development freaks wanted, especially for integrating the appropriate 
parts into existing frameworks such as Akonadi and Telepathy. And to motivate 
the effort for this development, we should come up with some one-liners and 
two-liners which show the power of the combination of OCS and its client 
implementations - for instance, something like:

for photo in ocs.my.contacts['laszlo'].dataset['photos']
	photo.save("/tmp/'%s'.jpg" % photo.name)

And I don't want to care how you ended up in my contacts list, by having met 
you on IRC or having played a game of chess against you yesterday. I just want 
your pictures, either as download or preferably even as updateable git 
repository :-)

> 5) Clearly define the strategy for trying to make server side
> implementetation(s), like getting python, php and so forth,
> contributors.

The main value here is adding OCS (wholly or partially) to existing SaaS with 
a broad installation base. I'm thinking of social network frameworks and 
personal cloud control centres, for instance, and would volunteer to continue 
this integration path along my ongoing projects.

> I have also further ideas, like marketing around the Standard and
> collecting potential clients for getting involved in the loop.. Also,
> the testing of the API itself that Henri was pushing previously, and
> so forth, but any good kick-off meeting would be brilliant, at least
> in my opinion. =)

It's always hard to market stuff which is written on paper, no matter how much 
value it has. Are these tiny web banners still en vogue? I would encourage 
creating them and adding them to web pages which support the API. In terms of 
timing, we should see how realistic is it to get a stable v2 in line with 
broad client support for the launch of KDE SC 5.

Josef