[Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

[Eben Eliason]

On Fri, Jul 3, 2009 at 7:25 PM, Gary C Martin<gary at garycmartin.com> wrote:
> On 3 Jul 2009, at 23:50, Gary C Martin wrote:
>
>> On 3 Jul 2009, at 18:29, Eben Eliason wrote:
>>
>>> On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin<gary at garycmartin.com>
>>> wrote:
>>>>
>>>> On 2 Jul 2009, at 14:47, Eben Eliason wrote:
>>>>>
>>>>> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey
>>>>> Lim<alsroot at member.fsf.org> wrote:
>>>>>>
>>>>>> But in that case we should provide possibility to mark objects
>>>>>> that can
>>>>>> be shared(I guess sharing all local objects by default is not a
>>>>>> nice
>>>>>> idea).
>>>>>
>>>>> Right. This would be essential. There's definitely some thought that
>>>>> needs to be done here.
>>>>>
>>>>> Scott had an interesting proposal which basically exposed the
>>>>> Journal
>>>>> (or some subset of it) as an RSS feed. This was really neat, because
>>>>> it meant we could build a UI for someone else's Journal in Sugar,
>>>>> populating it with that data, but also that these feeds could be
>>>>> shared globally, for anyone with an RSS reader to benefit from.
>>>>> That's
>>>>> a really powerful approach in my mind, and there is some starter
>>>>> code
>>>>> lying around as a proof of concept already!
>>>>
>>>>
>>>> +1 to rss feed concept, makes life a lot easier in a heterogeneous
>>>> environment.
>>>>
>>>> I'm still catching up on email so apologies if this has been
>>>> mentioned
>>>> already. But the UI for marking of entries as sharable does not
>>>> necessarily
>>>> need to be another Journal user-interface addition** In the simplest
>>>> approach you could just extend the Activity "Share with: my
>>>> Neighbourhood"
>>>> control to mark a Journal entry as part of the RRS feed. Would need
>>>> some
>>>
>>> The problem I see with this is that we're talking about two different
>>> kinds of sharing. Just because I want to make a picture I drew
>>> available for anyone to look at, or even make a "photocopy" of to
>>> scribble on, doesn't mean that I want to let them into a shared
>>> painting session so they can scribble on the original with me.
>>>
>>> This is the difference between sharing an activity with someone
>>> collaboratively, and sending them (a copy of) the resulting object.
>>
>> Devils advocate here, so just because someone was late to the realtime
>> party, they don't get to download an otherwise openly published piece
>> of work that could be re-published at any time by any of the
>> temporally lucky contributors? Downloading a Journal entry would not

I think you misunderstand me, as I think I'm arguing exactly the
opposite. I wouldn't want to deprive people the ability to download
finished works because the sharer doesn't want to open the document up
for public collaboration. The distinction is important, so that it's
possible to share things with others without having to make my own
documents open to collaboration.

>> allow you in anyway to edit the remote users copy, you'd just get a
>> snapshot downloaded to your Journal as if they had performed an
>> equivalent "Send to" function.

Exactly. If you conflate public vs. private states for documents with
the collaboration sharing scope, every public document would also be
open for public collaboration, which might not be desired, and might
discourage people from sharing their output.

> Replying to myself, always a bad sign ;-)
>
> Use case: "Darn, I missed the weekly project chat meeting, AGAIN... Oooh,
> Bob is still online, let me see if I can download the meeting activity
> entry."

This might not be the best example, since by definition the chat
meeting is an open collaboration, with a "neighborhood" (for example)
sharing scope.

> Misc supporting argument: If you default to Journal sharing OFF and make it
> a new separate manual public sharing UI tick box/setting (required for

I'm not necessarily stating that it should be off by default
(everything private). I'm simply arguing that it should be independent
of the collaboration scope. What may make sense (maybe this is what
you meant?) is to default all documents which become shared with the
neighborhood to public, while all others would default to private.

Eben

PS. I think we need to come up with some better terminology to
distinguish between collaboration sharing and journal sharing. That
would make this much easier to talk about.


> privacy), folks will rarely set it, there will be little to share from
> someone else's Journal so you'll rarely bother looking for something
> remotely. Changing the Activity sharing language from "Share with:
> Neighbourhood" to "Share with: Anyone", means both synchronous and
> asynchronous sharing could happen, suddenly allows deployments to
> automatically** cross pollinate content and activities as folks move from
> otherwise isolated network islands.
>
> **by automatically, I mean that the sharer has not needed to be asked to
> provide specific access to some entry, if it already was public, then it is
> shared. Though this does suggest to me that we should finally be allowed to
> "un-publicly share" an entry if desired (a manual choice); and perhaps a
> global manual setting for deployments/users to switch of all Journal
> sharing.
>
> Regards,
> --Gary
>
>