Re: [Wikitech-l] Snuggle, Huggle, and VandalSniper
Hi, If you found anything that VandalSniper can do and huggle can't, you can request it as a new feature and it will likely be there in next version, quick overview - this is what it has on its page * Unlimited browser tabs. - we don't have tabs in huggle now because I lack any use for them * Uncluttered, resizable UI. - huggle has very customizable UI as well * Changes listed on the Recent Changes tab display various characteristics of the edit, which can be used to locate likely vandalism. - huggle can do much more than just that * User links are annotated with a red link that will display a menu of common user-related tasks. - huggle has a number of user options * Edits of blacklisted users are displayed in realtime. - ALL edits are displayed in real time in huggle * Similarly, edits to watchlisted pages are displayed in realtime. - ALL edits are displayed in real time in huggle * Cross platform. (Theoretically at least. Linux is the only OS known to run it, but Microsoft Windows should support it soon.) - not just theoretically it works on Windows, MacOS and Linux (we distribute installer packages for all 3) + some other OS like Android or iOS could work as well according to Qt but there isn't any good justification to support huggle there Suggestions welcome! On Mon, Aug 4, 2014 at 9:59 PM, Pine W wiki.p...@gmail.com wrote: I just saw a reference to VandalSniper for the first time [1]. Would there be any use looking at it for ideas or code that would benefit Snuggle or Huggle? I believe that Snuggle and Huggle are in active development while VandalSniper has stalled, but VandalSniper reminds me of Snuggle. Pine [1] https://en.wikipedia.org/wiki/User:Crazycomputers/VandalSniper ___ 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] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
Hi all. WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together. Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things: - encourage feedback by absolutely /anyone/ about the next features they'd like, - run programming and documentation activities requested (or started) by community [there would be a lot of small projects, unlike the big ones the current Teams are working on], - encourage localising documentation for, and centralising the location of, all community-developed programming work, - raise awareness of community development efforts across all Wikimedia projects, - actively encourage members of community become MediaWiki and Gadgets hackers in the Free Software philosophy? This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support). Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea. Regards Gryllida. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Migrating test.wikipedia.org to HHVM
(apologies for cross-posting) On either Thursday or Friday of this week, Giuseppe Lavagetto (of the Wikimedia TechOps team) and I are planning to migrate https://test.wikipedia.org/ (testwiki) to HHVM. The way testwiki is configured makes it a natural next step on the path leading from the Beta Cluster to production. Specifically, testwiki is served by the same load-balancer, reverse-proxy, and database servers as the rest of production, but it is powered by a single application server that is segregated from the pool of servers that handle requests for all other Wikimedia wikis. This means that if we run into stability issues with HHVM, they will be confined to just testwiki, and will not spill over to other sites. To migrate testwiki to HHVM, Giuseppe will need to take the server that powers testwiki off-line for several hours for re-imaging. Ordinarily, we design our infrastructure for redundancy and graceful failover, so we can take machines offline without impacting users. But the corollary to testwiki being a special case is that it is not configured in this way. As I explained above, this is just as well, because it means we can perform this work without disturbing the rest of the cluster. Giuseppe and I will provide additional notices via IRC and e-mail prior to beginning this work. We know that testwiki is used by a diverse user-base to test various MediaWiki software components and will do our best to minimize disruption to such users. Feel free to get in touch via e-mail or IRC (my nickname is 'ori') if you have concerns about the deployment. Thanks for your patience and understanding! :) Ori ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Migrating test.wikipedia.org to HHVM
Woohoo! -- brion On Aug 5, 2014 6:54 PM, Ori Livneh o...@wikimedia.org wrote: (apologies for cross-posting) On either Thursday or Friday of this week, Giuseppe Lavagetto (of the Wikimedia TechOps team) and I are planning to migrate https://test.wikipedia.org/ (testwiki) to HHVM. The way testwiki is configured makes it a natural next step on the path leading from the Beta Cluster to production. Specifically, testwiki is served by the same load-balancer, reverse-proxy, and database servers as the rest of production, but it is powered by a single application server that is segregated from the pool of servers that handle requests for all other Wikimedia wikis. This means that if we run into stability issues with HHVM, they will be confined to just testwiki, and will not spill over to other sites. To migrate testwiki to HHVM, Giuseppe will need to take the server that powers testwiki off-line for several hours for re-imaging. Ordinarily, we design our infrastructure for redundancy and graceful failover, so we can take machines offline without impacting users. But the corollary to testwiki being a special case is that it is not configured in this way. As I explained above, this is just as well, because it means we can perform this work without disturbing the rest of the cluster. Giuseppe and I will provide additional notices via IRC and e-mail prior to beginning this work. We know that testwiki is used by a diverse user-base to test various MediaWiki software components and will do our best to minimize disruption to such users. Feel free to get in touch via e-mail or IRC (my nickname is 'ori') if you have concerns about the deployment. Thanks for your patience and understanding! :) Ori ___ Engineering mailing list engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.p...@gmail.com wrote: I am asking Quim to provide us an update. Me? :) I'm just an editor who, like many of you, has suffered this problem occasionally. On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER rupert.thur...@gmail.com wrote: that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis. TWiki is an open source wiki and also has (had?) a concept of blocking a page while someone else is editing. This feature might sound less than ideal in the context of, say, Wikipedia when a new Pope is being nominated, but I can see how many editors and MediaWiki adminis have missed such feature at some point. If I understood correctly, VisualEditor already represents an improvement vs Wikitext because the chances of triggering conflicting edits are smaller, because of the way the actual content is modified and updated in every edit. There was some idea to add to VisualEditor Etherpad-like concurrent and real-time editing, but maybe JamesF or marktraceur know better the current status. Rupert, in any case you see that the trend is going in the direction of being more efficient handling concurrent edits. Blocking pages while another editor supposedly is working on them might work in e.g. corporate wikis where most f the times the Edit link is clicked for a reason, but it could be potentially counterproductive in sites like Wikipedia. Just my 2 cents not even being an expert in this topic. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
With due notes that I just yesterday updated my nick and my e-mail, and I'm the one who started this thread; On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote: - encourage feedback by absolutely /anyone/ about the next features they'd like, Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only bugs. 99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it. - run programming and documentation activities requested (or started) by community [there would be a lot of small projects, unlike the big ones the current Teams are working on], I for one would welcome more initiatives and requests from the community. The PyWikiBot is a good example of a team that asks us to help organizing and promoting their special activities. More proposals are welcome. Listening to me (or other mailing list members) here or in your personal e-mail is not the way to go, as mentioned in my earlier line. - encourage localising documentation for, and centralising the location of, all community-developed programming work, Nemo has been a very active advocate, and I want to believe that WMF teams have been increasingly relying on centralized and translatable documentation in their releases, asking explicitly for translation help. I had trouble talking with Nemo. He doesn't go in lengthy discussions about development and explaining things on IRC. Is he more willing to follow-up and give examples over e-mail? Probably; I have not tried. On the plus side, I've had infinitely nice experience with him regarding translations of documentation. - raise awareness of community development efforts across all Wikimedia projects, This is an explicit goal for Tech Ambassadors and Community Liaisons. Related message: http://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073696.html - actively encourage members of community become MediaWiki and Gadgets hackers in the Free Software philosophy? Ah, you are touching a point of my personal ToDo list that I know we are not addressing as well as we could. That is correct, and is the problem. Still, we are trying to focus this line of activity in conjunction with our participation in Google Summer of Code, FOSS Outreach Program for Women, and recently also Google Code-in and Facebook Open Academy. Those, and IEG/PEG grants, scratch only a very small part of the userbase, and only their bigger projects. The problem is with engaging a vast majority of userbase in scripting the software to meet their personal needs. See, for instance, with Firefox, customizing is exceptionally easy using existing add-ons or writing your own using the Jetpack. These are well-documented technologies and they're also, unlike what happens at Wikimedia projects, well advertised to end users. Would you like to see MediaWiki as openly customizable as Firefox? This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support). To me this is not a task of one team or two, but a set of practices better embodies in our development and deployment processes, and also a set of activities that a larger community should embrace. In fact, this is what my Wikimania session is about! Shameless plug: https://wikimania2014.wikimedia.org/wiki/Submissions/The_Wikimedia_open_source_project_and_you Wikimania people are a tiny part of the userbase. _How_ would you do what you're talking about there? This is not mentioned in the abstract, even though the problem raised is similar. (It was scheduled at the Technology, Interface Infrastructure track but believe me, it's more about WikiCulture Community.) I'm curious about the subject of you message, especially the let's elect people part. What do you mean? Community volunteers could be featured for their technical work, and get rigorous feedback from community. If some of them start doing it contrary to community expectations, there should be means to clearly display that (and kick them out if they start doing rubbish and fail to hear the said feedback). -- This is very unclear and unspecific. I would expect others to come up with a specific mechanism for such cases. Svetlana. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
Thanks for the update Quim. I hope it gets done as soon as possible, as it'll go a long way to help multiple concurrent edits. I think it's been lacking for a long time now, and can't wait to see it in action. +Rexford https://plus.google.com/+Nkansahrexford | +CG Central https://plus.google.com/b/103109918657638322478/103109918657638322478/posts | +233 266 811 165 l BFCT http://www.blendernetwork.org/member/nkansah-rexford-nyarko/ On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil q...@wikimedia.org wrote: On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.p...@gmail.com wrote: I am asking Quim to provide us an update. Me? :) I'm just an editor who, like many of you, has suffered this problem occasionally. On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER rupert.thur...@gmail.com wrote: that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis. TWiki is an open source wiki and also has (had?) a concept of blocking a page while someone else is editing. This feature might sound less than ideal in the context of, say, Wikipedia when a new Pope is being nominated, but I can see how many editors and MediaWiki adminis have missed such feature at some point. If I understood correctly, VisualEditor already represents an improvement vs Wikitext because the chances of triggering conflicting edits are smaller, because of the way the actual content is modified and updated in every edit. There was some idea to add to VisualEditor Etherpad-like concurrent and real-time editing, but maybe JamesF or marktraceur know better the current status. Rupert, in any case you see that the trend is going in the direction of being more efficient handling concurrent edits. Blocking pages while another editor supposedly is working on them might work in e.g. corporate wikis where most f the times the Edit link is clicked for a reason, but it could be potentially counterproductive in sites like Wikipedia. Just my 2 cents not even being an expert in this topic. ___ 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] Feature request.
On Aug 5, 2014 11:25 PM, Nkansah Rexford nkansahrexf...@gmail.com wrote: Thanks for the update Quim. I hope it gets done as soon as possible, as it'll go a long way to help multiple concurrent edits. I think it's been lacking for a long time now, and can't wait to see it in action. I think some test cases are in order. The UI isn't perfect (you could even say confusing if you're not familiar with it) but IME (in my experience) edits are not lost. The conflict is either resolved automatically (so both are saved, not one clobbers the other *OR* it can't be resolved automatically and the 2 versions (current revision and what you just saved) are both sent back to the user for manual intervention. You can then diff (show changes), etc. -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. This issue is relevant to WMF and thematic organization staff email accounts, on-wiki accounts especially those with CU/OS and Arbcom roles, and other sensitive Wikimedia credentials. This issue also relevant to staff and volunteer accounts with third party services like Google Docs, Gmail, Skype, etc that are used to conduct Wikimedia related activities. Pine [1] http://mobile.nytimes.com/2014/08/06/technology/russian-gang-said-to-amass-more-than-a-billion-stolen-internet-credentials.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
