8 Nov
2010
8 Nov
'10
10:35 a.m.
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
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").
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.
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 that it's
some work and might be too much for this version.
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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. 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?