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 least >> 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. > Also as I wrote you can send to a group and to everyone too so yes you can > send to multiple people. I'm not talking about sending a message to groups, but to multiple individuals. >> 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 ? > > 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” 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. > * 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! 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 ? […] >> 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. > > 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. > >> 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. > > This is exactly what you do with your email and I don’t think you can say > that email is useless… 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. […] >> 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 disagree with you and I’ve already explained in details the reasons in a > bullet point list. > >> 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 thing. It’s > like saying: “having emails displayed in the order they are sent is a bad > idea”. 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. > The way even stream events are displayed is an implementation detail. They > can be filtered, grouped, etc. 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. > >> 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. > > 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. 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 chat feature Actually, I don't think that a chat feature would be mandatory, but I do 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" 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 > What I’m saying: > * We don't have chat feature and that’s a very large feature to develop with > a completely different architecture. At least we agree on that :) > * 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. 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. > * 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 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)") ;) > * I don’t see why messaging would be bad and affect the XWiki usage negatively. Especially since message stream is off by default. See the beginning of my response. > Thanks > -Vincent Thanks, Clément [1] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow
