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

[Gary C Martin]

On 4 Jul 2009, at 03:13, Eben Eliason wrote:
> On Fri, Jul 3, 2009 at 7:25 PM, Gary C Martin<gary at garycmartin.com>  
> wrote:
>>> 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.

OK, yes thanks, I see this issue now: I might want folks to be able to  
download an entry, but I might well want to work on it privately, by  
myself.

>>> 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.

Yep.

>> 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.

FWIW: I was assuming all chat participants has stopped the Activity  
(so not available in the neighbourhood), but that Bob (and his buddy  
icon) were still online.

>> 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.

Yes that's what I was trying to say :-) default all documents which  
become shared with the neighborhood to public :-) Though I'd missed  
your point that we would need some other UI in addition to this  
default, to allow someone to share an entry without collaboration.

Using the current Activity "Share with:" UI would indeed likely  
conflate collaboration with sharing, though it could still be worth  
investigating. Something along the lines of 3 modes "Private",  
"Collaborate with Neighbourhood", "Public Journal entry" (where  
"Collaborate with Neighbourhood" was collaborative and a public  
Journal entry).

> 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.

You're not kidding there :-)

Regards,
--Gary