Re: [Wikitech-l] global cleanup of nowiki
Subramanya Sastry schreef op 2015/06/20 om 10:49: On 06/20/2015 11:45 AM, Arlo Breault wrote: On Friday, June 19, 2015 at 1:38 AM, Amir E. Aharoni wrote: There may be more - I'm still looking for these. I was reading the discussion on gradually enabling VE for new accounts [3] and Kww writes there, Further, we still have issues with stray nowiki tags being scattered across articles. Until those are addressed, the notion that VE doesn't cause extra work for experienced editors is simply a sign that the metrics used to analyze effort were wrong. Jdforrester, can you explain how a study that was intended to measure whether VE caused extra work failed to note that even with the current limited use, it corrupts articles at this kind of volume [4]? Why would we want to encourage such a thing?” Makes me sad. User:Whatamidoing (WMF) (Sherry Snyder) has noted there that User:Kww might have been confused by the fact that the filter includes nowikis added by editors during normal wikitext editing ( see https://phabricator.wikimedia.org/T53421 ). In reality, the number of nowikis from VE edits are a minor fraction of the nowiki entries there (which I verified a couple days back by clicking through to the diffs in the AbuseLog), and the couple of sources of those nowiki insertions might have already been fixed as noted earlier in this thread. All that said, yes, we do want to and will continue fixing any sources of nowikis that Parsoid is introducing. Last I looked, the edits from Visual Editor were still a trivially small percentage of edits, much smaller than the minor fraction noted here. Where is the actual percentage tracked these days? KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Obfuscating IP addresses on history pages
Cristian Consonni schreef op 2015/04/08 om 3:00: 2015-04-05 17:31 GMT+02:00 Brian Wolff bawo...@gmail.com: Things that come to my mind: *range blocks become impossible, and its impossible to tell if vandals are using near by ips *cant do a whois on the ip to see if its a library or something Oh, I didn't think about this! What about: * creating a new permission group (say IP watchers) that can see the IP in non-hashed form? * compile some sort of list and automatically tagging edits from schools and libraries? (this could be useful regardless of hashing IPs) You are solving a problem that doesn't exist and creating more serious ones. There really is no right to privacy as it extends to editing Wikipedia, and that the WMF has manufactured one is more a source of trouble then benefit. As it stands, pretty much any technically literate user can look at editing histories and begin contributing in analyzing vandalism patterns and making reports and decisions about them. I rely heavily on well-formed reports of vandalism by users that have already done the preliminary grunt work of detecting similar edits from people in the same geographic region or carrier, and I don't want anything that makes it more difficult for them to do it. Vandalism and block-evasion are *real* problems. The imaginary right to carry out public actions anonymously shouldn't get in the way of solving them. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Lists as first class citizens
I hereby nominate collections. Describes it well and, at least to my ear, helps convey a bit of the notion that it's a personal thing. KWW Risker schreef op 2015/04/04 om 8:08: Hi Jon - These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able to suppress information on the page, and the edits to the page show up in the contributions tables that are available for checkusers for review, I'm perfectly fine with these pages. (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on these pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other page on Wikipedia. They don't need a different level of scrutiny, just the same level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that. On the other hand, I think it would be a net positive if everyone stops calling these pages lists. Lists are a specific type of content that has existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and format. Thousands of users have had their own personal lists in their userspace for pretty much the entire history of the project, too. Thus, the subject line of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new pages lists as well, even if just talking in the vernacular, will be confusing. So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution) is fine. RIsker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Risker schreef op 2015/03/20 om 5:46: Nonetheless, if you were trying to illustrate that there are communication benefits in having an easily read flow of discussion, I don't think anyone is disagreeing with you about that, and simplification of the indentation system/process would be desirable no matter what underlying software is used for discussion. What is being said in this thread is that Flow does not do this now, and in fact is currently designed to prevent this from happening. Precisely. It takes the biggest problem we currently have and aggravates it. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Danny Horn schreef op 2015/03/17 om 21:08: And I'm glad to hear that this thread has come close to almost inspiring optimism. That's what I'm here for. In a sample of one. Still, I guess one finds solace where one can. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03: On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote: How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script? Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with new software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext. As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation. Risker/Anne Converting LQT to Wikitext would lose the major benefits of: * per-Topic watchlisting, * per-Topic category support, * Sortable views (with Filterable views on the roadmap [1]), as well as the immensely easier process for new-editors to be able to participate in discussions, and be notified about replies.[2] But it would provide the advantage of using the standardized discussion technique used in virtually all Wikimedia installations. There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Erik Moeller schreef op 2015/03/17 om 1:39: On Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did. There was significant community interest and momentum behind LQT including various votes to enable it [1], and there is significant interest in Flow now [2]. The main thing that prevented LQT from wider adoption was not lack of community interest, it was our decision to put the project on hold due to both major architectural concerns and resource constraints at the time. We've committed to providing an upgrade path, and this is our follow-through to that commitment. [snip] As for inconsistency and fragmentation of mediawiki.org, if anything, the conversion of LQT pages on mediawiki.org will create greater consistency as we're already using Flow on Beta Features talk pages ( https://www.mediawiki.org/wiki/Talk:Content_translation is a nice example of a feedback page with lots of continuous and substantive comments from experienced users). I'm not arguing that nuking LQT isn't a good idea: that most certainly is. What I object to is this apparent intent to create two tiers of users: one tier that knows how to use the software and another tier that gets accustomed to a partially functional easy layer that provides no experience or training in how to maintain the actual project content, with no apparent bridge between the two. Between VE and LQT, newbies get provided with no experience in handling the easy cases of editing until they hit something that the simple tools can't handle, at which time they are suddenly faced with a wall of text that they have no experience in dissecting, parsing, and understanding and are expected to make a change in one of the hard parts. Much better to get them gradually accustomed to wikitext by performing small tasks than to just toss them in the deep end after their crutches break. Yes, there are at least five mixed metaphors in that last sentence, buy you get the drift. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Nick Wilson (Quiddity) schreef op 2015/03/16 om 17:51: LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. I assume that the intention is to greater increase the divide between Wikipedia editors and the Wikimedia Foundation? It would be nice if the WMF would focus on becoming good with the tools that editors use instead of attempting to convince them that inadequate substitutes are adequate. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor proxy with blinded tokens
Chris Steipp schreef op 2015/03/10 om 7:23: Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think. The easiest way to prevent a series of Tor bashing threads is to not make Tor promoting threads. At least for English Wikipedia, there is no reason now or in the conceivable future to permit, much less endorse or formalise, editing via Tor. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor proxy with blinded tokens
Chris Steipp schreef op 2015/03/10 om 9:00: On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: Chris Steipp schreef op 2015/03/10 om 7:23: Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think. The easiest way to prevent a series of Tor bashing threads is to not make Tor promoting threads. At least for English Wikipedia, there is no reason now or in the conceivable future to permit, much less endorse or formalise, editing via Tor. I believe there is a strong reason for it. Even if you use https for every connection to Wikipedia, traffic analysis currently makes finding out what you're reading fairly easy. From a risk perspective, if a user wants to edit Wikipedia on a subject and from a location that could endanger themselves, I would much prefer they edit via tor than rely on the WMF to protect their identity. Wikipedia isn't worth endangering oneself over, and we shouldn't encourage the delusion that any technical measure will change that. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stance on Social Media
Max Semenik schreef op 2015/01/09 om 16:41: On Fri, Jan 9, 2015 at 3:15 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: Not sure where to reply to a top-post to a bottom posted thread, so I will shoot for the middle and hope people can keep track of this knot. Your counterexample (which can be manually done today, so I've got experience with it) invariably winds up with a fan-flood of inexperienced editors and we wind up semi-protecting the article to keep them from damaging it. Since when an inflow of new editors is a bad thing? Of course, not all newbies will become productive editors, but if we start outright potential new people, we will end up with Wikipedia ran by three grumpy cats. See Citizendium for an example of a wiki that failed because it couldn't maintain a stream of new contributors as old ones were leaving. Who said an inflow was a bad thing? It's not. A surge all focused on one particular topic is a bad thing, a random distribution focused on a random group of topics is a good thing. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stance on Social Media
Brian Wolff schreef op 2015/01/09 om 15:17: I think its important to separate two types of social media interaction: *allowing people to post their favourite article (share this links) *meta level interaction (stuff about the community) Nobody objects to the second afaik. The first is like proposing nsfw filters on commmons (ie get ready for the pitchforks). You missed the worst part: Some evil administrator won't let me post that Mariah Carey/Iggy Azalea/pop singer of the week sold 50 bajillion copies of her latest album! Fans Unite, and make sure that Wikipedia has the TRUTH! accompanied by an edit this article link to the singer's article. The last thing we need to do is make that kind of crap easier. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stance on Social Media
Max Semenik schreef op 2015/01/09 om 16:01: As always, if there is a way to do something, there will be a way to abuse it. Remember when we enabled IPv6 support some people started moaning that new style IPs are vandalising even though the rate of vandalism wasn't different between IPv4 and IPv6 anons? This is the same situation: to your example one can always provide a counterexample, OMG the article about our favorite singer is so crappy, let's all help make it awesome! Is that bad? Even someone as hating social networks as me has to agree that by now, there's no rational reason not to add social sharing buttons. Not sure where to reply to a top-post to a bottom posted thread, so I will shoot for the middle and hope people can keep track of this knot. Your counterexample (which can be manually done today, so I've got experience with it) invariably winds up with a fan-flood of inexperienced editors and we wind up semi-protecting the article to keep them from damaging it. KWW On Fri, Jan 9, 2015 at 2:25 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: Brian Wolff schreef op 2015/01/09 om 15:17: I think its important to separate two types of social media interaction: *allowing people to post their favourite article (share this links) *meta level interaction (stuff about the community) Nobody objects to the second afaik. The first is like proposing nsfw filters on commmons (ie get ready for the pitchforks). You missed the worst part: Some evil administrator won't let me post that Mariah Carey/Iggy Azalea/pop singer of the week sold 50 bajillion copies of her latest album! Fans Unite, and make sure that Wikipedia has the TRUTH! accompanied by an edit this article link to the singer's article. The last thing we need to do is make that kind of crap easier. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] changing edit summaries
Derric Atzrott schreef op 2014/11/13 8:42: Indeed - I am somewhat surprised by James's firm opposition. I tend to agree with James on this one in that if the edit summaries are to be modified then they need a revision history. I don't know if they need an edit history per se. A log of changes would be sufficient. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] changing edit summaries
Jon Robson schreef op 2014/11/13 10:59: I think this is a great idea and has always baffled me that you can't. I'm also a little confused by James comment. Maintaining an edit history of edit summaries seems overkill. As I understand it edit summaries are for aiding other editors. If we are worried about losing important information, maybe only the original editor and trusted editors with certain privileges should be able to edit them. As rarely as I side with James, I would be up in arms if people tried to introduce the ability to edit edit summaries without even a log. Using an edit summary laced with obscenities and invectives is an unfortunately common form of attack. To make it possible to do so, leave it up until your victim sees it, and then erase all traces of the attack would be an administrative nightmare. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revision metadata as a service?
Jeroen De Dauw schreef op 2014/11/09 0:29: Hey, I suspect it isn't done because it isn't a very good way to modify a complex embedded base of software, Lila. Generally, when modifying a complex embedded base, one designs first, iterates implementation and internal testing, and then releases a relatively complete piece of functionality. As far as I understand this is about adding a new service, not modifying complex existing behaviour. Is that wrong? Also, while I can't speak for Lila, it does seem to me she is suggesting to go with a simple solution that tackles a specific need well, as opposed to releasing something incomplete. The idea to build small dedicated units rather than monoliths is not something new or controversial in the world of software design. Even though it might be in certain insular communities. Her comment included 1. As an editor I'd like to flag a revision as reviewed/verified by me from the revision screen or list. 2. As an editor I want to see which revisions were verified/had second opinion by other editors. That's not a service by any definition I'm aware of, that's a user interaction, one that seems to presume the existence of the Wikimedia base. There's no doubt that there's a lot of leeway in terms of how much one implements in each release of software, but one should always have a reasonably clear image of the final target, know where the piece being implemented now fits into the final result, and take steps to ensure that each release is sufficiently complete to be useful. There have been some successful products built using the code first, design later method, but that doesn't mean it should be encouraged. Even SCRUM encourages you to have some idea of what the final result will be, even if each phase is scoped opportunistically. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revision metadata as a service?
I suspect it isn't done because it isn't a very good way to modify a complex embedded base of software, Lila. Generally, when modifying a complex embedded base, one designs first, iterates implementation and internal testing, and then releases a relatively complete piece of functionality. KWW Lila Tretikov schreef op 2014/11/08 12:37: We seem to really gravitate towards complexity on these things. How can we make them simple, addressing a very specific need. We can complicate later. Here is a scenario (which we should start with, not architecture) 1. As an editor I'd like to flag a revision as reviewed/verified by me from the revision screen or list. 2. As an editor I want to see which revisions were verified/had second opinion by other editors. *So instead of a long spec that attempts to solve for a ton of cases, let's start thinking about solving simple, direct pain-points, iteratively.* Can we do that? L On Fri, Nov 7, 2014 at 8:40 PM, Erik Moeller e...@wikimedia.org wrote: On Wed, Nov 5, 2014 at 11:21 AM, Gabriel Wicke gwi...@wikimedia.org wrote: What are the indexing requirements for this metadata? If fast access by specific properties is needed Most typically, I'm guessing you'd do stuff on a per-revision basis to show quality indicators and such on page histories or article pages via opt-in gadgets. Querying the entire corpus for articles with certain characteristics would be valuable though, especially for applications like offline exports. I just saw https://meta.wikimedia.org/wiki/Grants:IEG/Revision_scoring_as_a_service and wasn't even aware of that when I wrote the email -- there's definitely a lot of interest in a generic solution for this problem. Erik -- Erik Möller VP of Product Strategy, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Bryan Davis schreef op 2014/10/02 8:46: On Wed, Oct 1, 2014 at 11:27 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: Focusing on what signature we can obtain from (or plant on) the device and how to make that signature available to and manageable by admins is the key. I used to do this for a living in the name of credit card fraud prevention. Not only is it a difficult problem, but it is also evil. [snip] In a space where we are actually arguing that there is a potential of loss of life for exposed actors, I don't think that it is reasonable at all to discuss ways to increase the risk of exposure by creating and publishing (oh yeah, we are open source and open config for most things here) a recipe for tracking users in a durable fashion based on device fingerprints and other sticky token techniques. Anybody that risks death by editing Wikipedia is an idiot: no privacy system is secure enough and no information is important enough to make that a reasonable decision. Treating editing Wikipedia as some noble effort that we must protect by at the cost of increasing the vulnerability of the website is unreasonable. There's no sacred right to privacy involved in editing the kind of material found on Wikipedia. Recognizing that it is nothing more but a repository of pop culture would allow us to prioritize protecting the site over the imaginary right to privately edit articles about Disney starlets. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Marc A. Pelletier schreef op 2014/10/02 18:39: On 10/02/2014 09:07 PM, Kevin Wayne Williams wrote: Anybody that risks death by editing Wikipedia is an idiot: no privacy system is secure enough and no information is important enough to make that a reasonable decision. I wouldn't have put it that way, but I've been saying something to that effect to sockmasters for some time when they pull out the my security is in peril card -- editing Wikipedia is an intrinsically *public* activity, and if doing so places you at risk of harm then you should not be editing at all as no technology or privacy policy will protect you to that level. [...] Recognizing that it is nothing more but a repository of pop culture would allow us to prioritize protecting the site over the imaginary right to privately edit articles about Disney starlets. That, on the other hand, is a both unfair and unwarranted slur on the work of countless volunteers. Even those that /do/ work on topics of popular culture bring value, but that characterization is nothing short of a demeaning insult to all -- including those volunteers who slave away on the parts of the encyclopedia even the snottiest of elitist must admit has value to mankind. Check my edit history, and you will see that I spend the bulk of my time administering pop culture articles, including those self-same articles about Disney starlets. I'm surprised at the effort people put into it, but I respect it enough to prevent it from being vandalized. I'm just amused by people that view making such edits anonymously as some intrinsic right. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Derric Atzrott schreef op 2014/09/30 6:08: Hello everyone, [snip] There must be a way that we can allow users to work from Tor. [snip more] I think the first step is to work harder to block devices, not IP addresses. One jerk with a cell phone cycles through so many IP addresses so quickly in such active ranges that our current protection techniques are useless. Any child can figure out how to pull his cable modem out of the wall and plug it back in. Focusing on what signature we can obtain from (or plant on) the device and how to make that signature available to and manageable by admins is the key. Maybe we require a WMF supplied app before one can edit from a mobile device. Maybe we plant cookies on every machine that edits Wikipedia to allow us to track who's using the machine and block access to anyone that won't permit the cookies to be stored. There are probably other techniques. The thing to remember is that the vast majority of our sockpuppeteers are actually fairly stupid and the ones that aren't will make their way past any technique short of retina scanning. It doesn't matter whether a blocking technique allows a tech-savvy user to bypass it somehow. Anything is better than a system that anyone can bypass by turning his cable modem off and on. Once we have a system that allows us to block individual devices reasonably effectively, it won't matter whether those people are using Tor to get to us or not. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is simplicity is the key to success of Echo and Watchlist?
Ryan Kaldari schreef op 2014/09/01 22:59: - *it* *doesn't* *scale* (constantly seeing a (3) or new emails pop up if you're active in ~6 discussions is a pain) OK, so how do you suggest changing it? - _nothing_ on-wiki ever warrants an urgent reaction ever All the community members who clamored for the return of the Orange Bar of Death seem to disagree with you. You use the past tense. I *still* clamor for the Orange Bar of Death. When I leave someone a message on a talk page, chances are very good that message is something along the lines of if you do that again, your account will be blocked until you agree to stop. I want to be certain that the message has been seen before proceeding to the obvious next step. To me, the answer is obvious: pull messaging out of echo, and summarize notifications on echo for the remaining notifications (i.e. if a notification for a given page is already sitting unread, don't bump the number, and replace the message with x AND y have happened on z. For messages, give us back the OBOD. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
