10 Nov
2010
10 Nov
'10
8:21 p.m.
Le 08/11/10 15:54, Sergiu Dumitriu a écrit :
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On 11/08/2010 03:23 PM, Ludovic Dubost wrote:
Hey sergiu,
I challenge you. Put the "email this page" spec on xwiki.org
and tell "Hey bozos, this is critical, let's work on it" and then let's
see the turnaround speed about this spec without regular emails to the
dev list, and let's see how many comments about the spec will be put in
the wiki instead of being posted to the dev list.
Personnaly I would prefer the solution:
"Hey bozos, I've added you to the notification list for this document
since I believe it's and important one. You can opt-out anytime"
then
"Hey bozos, I've created this document. Think about clicking the
subscribe box so that you know about all changes"
The result is simple: half the people will forget doing it. The people
won't get notifications. The manager will finally have to resend emails
regularly to make things move.
This feature is trying to make the manager or content manager's life
easier. You are dismissing and "optional" feature for wrong reasons
which don't apply in the environment this feature is meant for.
Le 08/11/10 10:35, Sergiu Dumitriu a écrit :
So by sending much more emails we keep people off emails and in the
wiki? This logic really escapes me.
If the manager wants to invite people to actively be involved in writing
that document, he can send a notification once, telling in the custom
message that "Hey bozos, this is critical, let's work on it", and the
coworkers will find a way to work better together. Instant messaging is On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
I am talking about the "send notification to this bunch of
people EVERY
TIME THE PAGE CHANGES" with the possibility for users to opt out.
The objective, and I'm probably repeating myself, is allow for
PARTICULAR documents, to speed up the turnaround speed when working on a
document, to avoid the current side effect of having a parallel
discussion by email around the document without actually making any
changes to the document and leaving all the work to the initial author.
The objective is to NOT NEED a separate discussion, it's not like
Vincent seems to have understood it, to have discussions in the Wiki.
The objective is that you only work with Wiki changes and Annotations so
that you have a real workflow that really leads to improving the document.
Currently and without such a feature we are undermining the Wiki concept
by making it more difficult for people to centralize the content in the
Wiki. Therefore people will stick to emails and the whole benefit of
having a wiki page is moot.
The manual subscription mecanism is a progress and it would be great to
at least do that, but I can tell you that as a project manager, I would
find annoying to not have a way to invite 2 or 3 people to this
notification mecanism to make sure that the discussion can happen in the
wiki instead of having a parallel track in emails
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
> I don't like this, it's intrusive. Personally I wouldn't like at all
> being forcefully invited into a conversation. There are other ways of
> doing this which don't involve waking up with 30 emails in my inbox,
> most of which will be implemented in the 3.x cycle as part of the
> social
> improvements.
>
I don't agree with you that the social improvements do anything in this
area or maybe I'm missing something. If it's activity streams or other
real time features, oin many cases, you can't go all the time to the
wiki to check if an important document is evolving, for which the
discussion needs to be fast.
You might not like it, but this really creates dynamicity when
discussing on a wiki document.
The lack of such a features leads to discussions staying in email
exchanges and therefore no work on the wiki document itself (when it was
at all created).
Think about a discussion about a feature in the devs mailing list. None
of it is captured in the wiki page where the feature is described.
Think also about non technical people that need to learn how to work
with wikis.
I don't think we're talking about the same thing. I'm
referring to "send
notification to this bunch of people EVERY TIME THE PAGE CHANGES". I
agree about the "send notification", but not about the "every time".
I
also agree with subscribing myself to notifications (a.k.a. "add to MY
watchlist"). the best tool at the moment for fast collaboration.
Realtime editing
with integrated chat will be better. Email is just noise.
It might be noise but
that's what many people work with.
Realtime editing would be great but is not there, and still this does
not work with slower turnaround.
Aren't you receiving all xwiki's JIRAs in your email ? Aren't we auto
subscribed to ALL email threads of this list ?
Basically there is no intermediary between
1/ subscribe yourself to the pages that are important to you
2/ autosubscribe to all pages
What I'm proposing is to let my coworkers subscribe me to things that
they think are important to me, while letting me change that
In this end, this is about privacy. Why would we allow
people to push
things into other person's watchlist? Let's not go the Google Buzz way,
we'd better think of how features can be used wrongly, too.
Because they can
opt-out. In an intranet (work) environment I don't see
where the problem is (I repeat that this solution is intended for people
that already work together, not for total strangers).
The management of the company can decide wether or not this feature is
wanted internally (and can be off by default).
But if it's about privacy what about having an option where the user can
say he accepts auto subscription or not ?
Why not also trusting users to use this wisely ?
Ludovic
>>
Concerning being forced in a conversation, you can drop out in one click
>> if you don't like it and it's the responsibility of the person sending
>> the notification to actually decide to do that push.
>> Of course this should not be done by default on all documents as this is
>> meant for important docs for which a discussion is really needed, like a
>> project manager bringing in 3 people he works with in a discussion.
>> Managers need to be sure that what they want to do reaches their target.
>> If editing the wiki page or commenting on a wiki page is not sure to
>> reach it's target, the manager will reach out to other means (email,
>> skype or even telephone). Once this happens you have lost of lot of
>> valuable content.
>>
>> Without the forcing, you can be sure that since some people will be
>> missing the discussion won't work as well.
>>
>> In any case please don't think about this feature for public
>> discussions. It's meant for business users so that they can get the work
>> done.
>>> I agree about a "notify me of changes" checkbox under the action
>>> buttons, if Vincent doesn't think it crowds the editor UI.
>>>
>> That's definitively already usefull as any editor/commentor can decide
>> to get instant notifications.
>> But the minute you are not sure that the other user will get your
>> comment, people will loose confident is this way of discussing.
>>
>>>> Finally we could add an email box so that we can load comments sent
>>>> as a
>>>> reply to an email sent by the wiki.
>>> Yep, this is also an idea kept in the background, but too complex to be
>>> included inside the "email this page" development.
>> I agree that it's some work and might be too much for this version.
>>>> The rationale for this feature is that when working on a document that
>>>> requires some discussion and validation, the email discussion is not
>>>> captured and the changes in the wiki are not triggering a fast enough
>>>> reaction thus slowing down the discussion around the document (I know
>>>> the Watch List exists, but since it requires manual subscription, most
>>>> participants won't do it and the speed of notification of the watch
>>>> list
>>>> is not fast enough for discussion).
>>> One idea of improvement for the watchlist was to have instant
>>> notifications, but this is another topic. In summary:
>>>
>>> - add a new level for the watchlist which sends notifications as
>>> soon as
>>> a document is sent (as implementation, it will use the observation
>>> mechanism and not a scheduler job)
>>> - the current notification interval configuration will be kept as the
>>> default
>>> - for each item in the watchlist it will be possible to specify its own
>>> interval setting
>>>
>>>
>>> Isn't your last paragraph contradicting your proposal? Email is slow
>>> and
>>> deprecated, and one of the main points when presenting XWiki is how
>>> much
>>> better it is than emails. Why would moving the discussion to emails
>>> help
>>> collaborative writing?
>>>
>> email usage should move from being the actual place of discussion to a
>> notification tool.
>> It's still a good notification tool for the important ones. Clearly if
>> you are overloaded in one of your channels, then it's stops being
>> effective.
>> But well done it's a good notification tool. RSS or Twitter which are
>> good at being notification tool for massive amounts of information are
>> actually bad for the smaller amounts of important information.
>> In my view it's about learning how to use a combination of these tools
>> for that.
>>
>> Back to the wiki, my objective here is not to move the discussion to
>> emails, but to make sure that any discussion in the wiki get the same
>> efficiency as email when it comes to notification of the discussion
>> events. As for capturing responses in emails into the wiki this is to
>> ease transition from email to wiki. I would expect that experiences
>> users would click on the link to comment in the wiki since you would
>> have more features there.
>>
>> Ludovic