All others: if you have any recommendation or counter argument, please post it quickly :)

Hi Clement, [snip] This is not supported ATM (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Message%20Stream%20App…) so no issue FTM. You can only send messages to a given user, to a group or to everyone.> I don’t see a problem to add this feature later on if we need it.

I don’t see this related at all to messaging. You have the same problem for any kind of notifications. This is related to live notifications and something generic for the notifications feature. I don’t agree with "The messaging feature of the notification is interesting here if and only if we have the ability to auto-refresh the notification center every X seconds”. Again I don’t see why this is related only to messaging and also I find it more useful to have messaging than nothing (which is what you propose). I can imagine plenty of use cases where it’s still useful to have messaging without the auto refresh. I consider auto refresh to be a nice improvement to have not as a "must have or there’s no value”.

Maybe there’s a misunderstanding: We’re not trying to develop a messaging feature. This feature already exists and we’re not touching this. All that we’re doing is add the ability to display messages in the notification UI if some messages are present in the Event Stream table. This feature already exists today and not doing this would be to remove a feature that is now interesting to have thanks to the replacement of the AS by the Notifications UI. We disabled it for 2 reasons and not for the reasons you mentioned above: * Because the dashboard was on the home page and several users were not using the message sending UI and didn’t want it to take valuable space on the home page. This has been solved by moving the dashboard to a different space * Because you couldn’t know when someone was sending a message to you and it was hard to check your personal AS (you had to nav to your user profile).

Those 2 problems are fixed so there’s no reason to not have it anymore. Yes and that’s why Caty is going to conduct a more general investigation on that. I understand your POV and I don’t disagree with it in general. However, I feel that: * I don’t like regressing/loosing features * This is an opportunity to have something now. I can tell you that if we do nothing now, nothing will happen for at least 1 year * We’re not redoing the messaging feature, just the display part in the notif UI * I don’t see how there would much changes even if we spend 2 years designing a new messaging center. * It’s not going to cost much (probably 1-2 days of work max). So at worse ,it’ll cost us 1-2 days if we had to redo everything. * Also note that we're not changing the store or anything so even if we redo it completely differently it doesn’t matter and we will not loose anything * This will allow us to gather feedback from the community about needs/improvements * We can never implement a feature in one go. We need to work iteratively. We just need to make sure the architecture is not going to break. Since we’re not touching this part, there’s no real risk So I really believe that it’s more positive than negative to spend this little time to display messages in the notif UI. WDYT?

please post notification in would iki/bin/view/Extension/Message%20Stream%20Application/) so no issue FTM. You can only send messages to a given user, to a group or to everyone.> Did I say we should not think about it? Also as I wrote you can send to a group and to everyone too so yes you can send to multiple people. Ok so we have a big disagreement: * You say “displaying notifications in the proposed way is bad thing and there’s no use case for it” * I say “‘displaying notifications for those who want to send messages to a single person, to a group or to everyone is better than not being able to do it”. Also note that it’s disabled by default ATM so by default you get what you want, i.e. nothing! the to center new problem for any kind of notifications. This is related to live notifications and something generic for the notifications feature. interesting here if and only if we have the ability to auto-refresh the notification center every X seconds”. Again I don’t see why this is related only to messaging and also I find it more useful to have messaging than nothing (which is what you propose). I can imagine plenty of use cases where it’s still useful to have messaging without the auto refresh. I consider auto refresh to be a nice improvement to have not as a "must have or there’s no value”. Again we don’t agree about this. We’re not implementing a chat. We’re implementing message sending as in email sending. Live message sending is another feature. This is exactly what you do with your email and I don’t think you can say that email is useless… takes messaging feature. This feature already exists and we’re not touching this. notification UI if some messages are present in the Event Stream table. remove a feature that is now interesting to have thanks to the replacement of the AS by the Notifications UI. above: not using the message sending UI and didn’t want it to take valuable space on the home page. This has been solved by moving the dashboard to a different space and it was hard to check your personal AS (you had to nav to your user profile). spec investigation on that. However, I feel that: we do nothing now, nothing will happen for at least 1 year the notif UI designing a new messaging center. worse ,it’ll cost us 1-2 days if we had to redo everything. we redo it completely differently it doesn’t matter and we will not loose anything needs/improvements iteratively. We just need to make sure the architecture is not going to break. Since we’re not touching this part, there’s no real risk this little time to display messages in the notif UI. I disagree with you and I’ve already explained in details the reasons in a bullet point list. The event stream has nothing to do with weight. It’s a timeline thing. It’s like saying: “having emails displayed in the order they are sent is a bad idea”. The way even stream events are displayed is an implementation detail. They can be filtered, grouped, etc. Then you shouldn’t care at all since it’s not going to be used and you’re not the one implementing it. It’s also off by default. So reading between the line, in the end you’re saying: * We shouldn’t have a messaging feature because what we need is a chat feature * There’s no way that people could use messages, it’s not useful What I’m saying: * We don't have chat feature and that’s a very large feature to develop with a completely different architecture. * A messaging feature is still interesting even if we have a chat feature one day. Example use case: "send a message to everyone that the xwiki will be be upgraded tomorrow”, “ notify a group of person to review a document”, etc. * It costs little to be back to iso feature (1-2 days) and it’s taking almost the same amount of time just to discuss not doing it in this thread ;) * I don’t see why messaging would be bad and affect the XWiki usage negatively. Especially since message stream is off by default. Thanks -Vincent

I'm here describing my own usage of collaborative platforms or social networks. If it wasn't supported before today, maybe we should think about it, because usually, people with only one friend to talk to are rare. Having multiple conversation is something that we should at least think about.

Also, as you mentioned it in the end of your previous mail, "if we do nothing now, nothing will happen for at least 1 year", what makes you think that we'll have the time to improve the feature later on, even if we do need it ?

Yes, this is a feature that is also nice to have for all kind of notification, however, this is what I mean by "shipping a half finished feature" : messaging is something done in real time.

If you forget to refresh your page, you forget to get new messages. Imagine if you had to refresh a page every time you wanted to see a new message on IRC.

So we're putting back something that has been disabled by default since more than one year without giving it enough features to be usable for a standard user (things like being able to get messages in real time, for example). For me, it's both a waste of time, and this might even degrade the image of XWiki as it (IMO) won't be a very useful feature.

I think that sending messages into the event stream was kind of a bad idea from the beginning as messages don't have the same "weight" as other wiki events.

I do understand that you don't like loosing features, but since I've known XWiki, I've never heared of the Message Stream in a good, useful and productive way.

On 31 May 2018, at 17:28, Clément Aubin <aubincleme(a)gmail.com> wrote: On 05/31/2018 04:42 PM, Vincent Massol wrote: […] Oh I'm sure that you didn't said that, but this would need a more in-depth investigation, and not just 2 days of implementation.

I'm not talking about sending a message to groups, but to multiple individuals.

Please don't rephrase me like that :) . The current notifications are, IMO correctly displayed (and we're not debating about how to display notifications AFAIK).

However, I don't think that the notification center has been crafted to correctly display user messages. Merging events coming from the wiki and messages coming from the message stream is tricky.

It's disabled by default for now, but it's actually proposed to enable it, else the proposal (2) would not make any sense.

That also raises a problem : how can I be sure that you will be able to receive my message if I don't know in advance if you have enable or disabled your ability to receive messages in your notification preferences ?

[…] Ha ok, indeed, I didn't though about a non-live implementation of a messaging system. IMO that's still something old (as nowadays, almost every messaging system are live, even on forums and boards, that used to propose this idea of personal messages a lot).

This could be an improvement idea if and only if we have an "inbox" or something in which we can put the messages that a user received in order for him to check on them later.

[…] Using your example, you're not just displaying emails, you're also displaying a ton of notifications about the documents that have been updated in your wiki.

I don't think that you should require a user to tune his notification preferences in order not to be flooded by notifications. Having messages is kind of a risk here because this implementation detail does not protect the user enough from the messages hiding other important events.

See the beginning of my response. Actually, I don't think that a chat feature would be mandatory, but I do think that it would be more attracting to people. I see some use cases for live messages, but I'm indeed having a hard time seeing use cases for non-live messages as people can use another chat tool aside from their wiki if we don't propose an "inbox" solution. It won't be reliable to send a message as : * It can be filtered out by the recipient notification preferences * It can be ditched in the bottom of the notifications of a user if he / she does not clean his / her notifications quickly enough * There's no way to access this message once the notification center has been cleared At least we agree on that :) Note that what you described are events and can actually be implemented using the event stream, so I'm not sure that those are correct examples.

I don't like this idea as this is kind of discouraging the discussion on features that we have to put in the platform ([1], especially "Ensure agreement on the work being done (it's too stupid to do a lot of work and only find when it's finished that it wasn't the right way to do it and it has to be all redone again)") ;)

On 31 May 2018, at 18:07, Clément Aubin <aubincleme(a)gmail.com> wrote: On 05/31/2018 05:44 PM, Vincent Massol wrote: > > >> On 31 May 2018, at 17:28, Clément Aubin <aubincleme(a)gmail.com> wrote: >> >> On 05/31/2018 04:42 PM, Vincent Massol wrote: >> >> […] >> >>>> I'm here describing my own usage of collaborative platforms or social >>>> networks. If it wasn't supported before today, maybe we should think >>>> about it, because usually, people with only one friend to talk to are >>>> rare. Having multiple conversation is something that we should at

>>>> think about. >>> >>> Did I say we should not think about it? >> >> Oh I'm sure that you didn't said that, but this would need a more >> in-depth investigation, and not just 2 days of implementation. > > No no this is out of scope for now. > >> >>> Also as I wrote you can send to a group and to everyone too so yes

>> >> I'm not talking about sending a message to groups, but to multiple >> individuals. > > I know and out of scope for now. > >> >>>> Also, as you mentioned it in the end of your previous mail, "if we do >>>> nothing now, nothing will happen for at least 1 year", what makes you >>>> think that we'll have the time to improve the feature later on, even

>>>> we do need it ? >>> >>> Ok so we have a big disagreement: >>> * You say “displaying notifications in the proposed way is bad thing

>> >> Please don't rephrase me like that :) . The current notifications are, >> IMO correctly displayed (and we're not debating about how to display >> notifications AFAIK). > > Sorry I meant ‘displaying messages in the notifications UI in the

Mostly because user messages (as in private, user to user messages) can be related from one to another (ie : the message B that you just sent me is a response from the message A that I sent you). You will then need some context to display the response from someone in your notification center. I don't think that we have an easy way to do that now.

>> >>> * I say “‘displaying notifications for those who want to send

>>> >>> Also note that it’s disabled by default ATM so by default you get

>> >> It's disabled by default for now, but it's actually proposed to enable >> it, else the proposal (2) would not make any sense. > > It’s not proposed FTM. Maybe you’re mixing the display of messages when

I'm talking about user messages as in [1] ; so private, user to user messages. >> That also raises a problem : how can I be sure that you will be able to >> receive my message if I don't know in advance if you have enable or >> disabled your ability to receive messages in your notification

> > The proposal Guillaume is implementing is to have them enabled by

> > But indeed that could be refinement in the future that you can’t send

> >> >> […] >> >>>> Yes, this is a feature that is also nice to have for all kind of >>>> notification, however, this is what I mean by "shipping a half

>>>> feature" : messaging is something done in real time. >>> >>> Again we don’t agree about this. We’re not implementing a chat. We’re

>>> >>>> If you forget to >>>> refresh your page, you forget to get new messages. Imagine if you

>>>> refresh a page every time you wanted to see a new message on IRC. >>> >>> This is exactly what you do with your email and I don’t think you can

>> >> Ha ok, indeed, I didn't though about a non-live implementation of a >> messaging system. IMO that's still something old (as nowadays, almost >> every messaging system are live, even on forums and boards, that used

>> propose this idea of personal messages a lot). > > email is old but the most used system :) So old doesn’t mean useful! > >> This could be an improvement idea if and only if we have an "inbox" or >> something in which we can put the messages that a user received in

>> for him to check on them later. > > Yes notifications is an inbox for notifications. We have that already.

> >> >> […] >> >>>> So we're putting back something that has been disabled by default

>>>> more than one year without giving it enough features to be usable

>>>> standard user (things like being able to get messages in real time,

>>>> example). For me, it's both a waste of time, and this might even

>>>> the image of XWiki as it (IMO) won't be a very useful feature. >>> >>> I disagree with you and I’ve already explained in details the reasons

>>> >>>> I think that sending messages into the event stream was kind of a bad >>>> idea from the beginning as messages don't have the same "weight" as >>>> other wiki events. >>> >>> The event stream has nothing to do with weight. It’s a timeline

>> >> Using your example, you're not just displaying emails, you're also >> displaying a ton of notifications about the documents that have been >> updated in your wiki. > > We’re displaying notifications. > >> >>> The way even stream events are displayed is an implementation detail.

>> >> I don't think that you should require a user to tune his notification >> preferences in order not to be flooded by notifications. Having

>> is kind of a risk here because this implementation detail does not >> protect the user enough from the messages hiding other important

> > I don’t understand your point. Why would a user tune anything? A user

> > If they select too many then they’ll have the same issue you have with

> >> >>> >>>> I do understand that you don't like loosing features, >>>> but since I've known XWiki, I've never heared of the Message Stream

>>>> good, useful and productive way. >>> >>> Then you shouldn’t care at all since it’s not going to be used and

>> >> See the beginning of my response. >> >>> So reading between the line, in the end you’re saying: >>> * We shouldn’t have a messaging feature because what we need is a

>> >> Actually, I don't think that a chat feature would be mandatory, but I

>> think that it would be more attracting to people. >> >>> * There’s no way that people could use messages, it’s not useful >> >> I see some use cases for live messages, but I'm indeed having a hard >> time seeing use cases for non-live messages as people can use another >> chat tool aside from their wiki if we don't propose an "inbox"

>> >> It won't be reliable to send a message as : >> * It can be filtered out by the recipient notification preferences >> * It can be ditched in the bottom of the notifications of a user if he

>> she does not clean his / her notifications quickly enough >> * There's no way to access this message once the notification center

>> been cleared >> >>> What I’m saying: >>> * We don't have chat feature and that’s a very large feature to

>> >> At least we agree on that :) >> >>> * A messaging feature is still interesting even if we have a chat

>> >> Note that what you described are events and can actually be implemented >> using the event stream, so I'm not sure that those are correct

> > A message is an event for which the content is defined by the user. Not

Not sure about what you mean too then … following your definition, [1] is then a user message and [2] and [3] are not. At least, that's what I understand as "user messages”.

>> >>> * It costs little to be back to iso feature (1-2 days) and it’s

>> >> I don't like this idea as this is kind of discouraging the discussion

>> features that we have to put in the platform ([1], especially "Ensure >> agreement on the work being done (it's too stupid to do a lot of work >> and only find when it's finished that it wasn't the right way to do it >> and it has to be all redone again)") ;) > > What? You lost me completely here. > > Why does it discourage discussions to implement something? > > If you’re interested in working on a chat system in xwiki, please knock

[1] http://design.xwiki.org/xwiki/bin/view/Proposal/

[2] http://design.xwiki.org/xwiki/bin/view/Proposal/

[3] http://design.xwiki.org/xwiki/bin/view/Proposal/

Hi, (sorry for not reading the discussions above, I hope to get to read them at some point) I just wanted to remind you that: 1. We (at least I did) have previously concluded that it was a *mistake* to mix notifications with messages. 1.1 Notifications have transient lifecycle and can be easily discarded. The previous ActivityStream implementation actually had a periodic notifications/events cleaner that would automatically delete events older than (e.g.) 30 days, for both storage and performance reasons. 1.2 Messages have a much longer lifecycle, some users choosing to never delete them and keep record of all conversations they ever had with someone. 1.3 Mixing storage for the 2 is a recipe for disaster, IMO, and, if/when we plan to handle it seriously, we should either implement or integrate a separate solution for messaging, both on the storage and the UI level. IMO, the biggest intersection between Notifications and Messaging is the ability to receive a notification about the fact that you have received a message from X. Reading the message and acting upon it (i.e. replying, etc.) should be done in the dedicated UI of the Messaging Application (i.e. inbox/etc.). 2. We *don't have to* and *shouldn't* keep all the features of the previous system. Instead, this was supposed to be a good opportunity to improve on our previous mistakes, not repeat them, in a new and improved system. 3. The Network/Follow feature is still a nice feature to stay up to date with the activity of some users of interest. The "Send message to followers", however, is, IMO, outside the scope of Notifications. 4. When talking about Messaging, we can also distinguish 2 types of messages: public and private. 4.1 Private messages should, IMO, necessarily be addressed with the Messaging application detailed at 1. Also, private messages need to be trustworthy, as they can/do usually contain sensitive information. The data should not be deleted and it should be properly protected. 4.2 Public messages, that have a more transient nature, could be the scope of some "Announcements" application, that could behave as Notifications. Couple that with the ability to interact with events (i.e. reactions or comments on the page displayed under the event) and you get a very live and social environment. Thanks, Eduard On Thu, May 31, 2018 at 7:19 PM, Vincent Massol <vincent(a)massol.net> wrote: wrote: social think are do you even are, stream me enable when to scope We’re can or reasons bad detail. he review a implemented Not described examples.”. this it knock from