Re: [Wikitech-l] Link how to install media wiki from git on MAC
Though I generally do not recommend it, you can find OSX setup instructions here: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Mac_OS_X Cheers, Rob On Fri, Dec 7, 2012 at 9:24 AM, Harsh Kothari wrote: > Can anyone give the link how to install mediawiki from git on MAC OSX ? > > Thanks in advance > Harsh > --- > Harsh Kothari > Research Fellow, > Physical Research Laboratory(PRL). > Ahmedabad. > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure Coding Documentation
This is great Chris. Airport wifi permitted, I will gladly tune in. On Wed, Dec 19, 2012 at 7:11 PM, Chris Steipp wrote: > Hi Everyone, > > I'd like to invite anyone interested to join in on a secure coding > documentation sprint on Friday of this week (Dec 21st), from 11:30am - > 12:30pm PST (19:30-20:30 UTC). If you're interested in joining, but > can't make that specific time, let me know and we may hold more of > these if there's interest. > > The goal of this sprint is to both help anyone who is interested learn > about some specific security vulnerabilities, and update our > documentation so that new developers can avoid these issues in the > future. > > On Friday, I would like to address a couple of topics where we have > very little documentation: > * DOM-based XSS, and writing secure client side code. Closely related > is general security for gadget developers. > * Protecting private information (i.e., when do developers need to > check if data has been deleted / suppressed) > > We'll spend a little time talking about each subject (and some > specific issues we've seen recently), and I'll have a rough article > outline in an etherpad. Then I would like everyone's help fleshing out > the documents so they are clear and informative for other developers > of all skill levels. > > I'll have both a google hangout for video, and an audio line for > anyone who prefers to avoid closed technology. If you want to dial in, > please let me know so I can get you a phone number in advance. > > Chris > > _______ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Munagala Ramanath (Ram)
Welcome Ram! On Tue, Jan 15, 2013 at 2:00 PM, Platonides wrote: > > Please join me in welcoming Ram! > > > > Rob > > It's always good to get more ram! :) > Welcome! > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML Validation Shell Script
Like a boss! Thanks Jon. On Wed, May 1, 2013 at 11:22 AM, Jon Robson wrote: > W3CValidationTest -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs
I personally know for a fact nobody is trying to trick the user in this case. We are simply trying to make editing easier for new editors without confusing them. As a membwr f the visual editor team, I'm supportive of our advanced and seemingly more important editors opt-out during the beta. — Sent from Mailbox for iPhone On Tue, Jul 23, 2013 at 21:23, Tim Starling mailto:tstarl...@wikimedia.org";>> wrote: On 23/07/13 04:36, Erik Moeller wrote: > 1) Section editing behavior - the hybrid link display is mildly > annoying, and doesn't work for touch interfaces; I think it's a bit more than mildly annoying, and I think it's the main reason users are so desperate to disable VE completely instead of simply not clicking on it. Consider it from a cognitive point of view: Half the time (e.g. on talk pages), the section edit link will go to the old edit page, and the other half, it will flash an "edit source" link at you for the 100ms or so it takes to stabilise the cursor position and execute a mouse click, and then it will launch the visual editor. Often, the user is punished for clicking on the wrong link by having their browser lock up for 15 seconds. Habit formation is cleverly avoided by changing the function of the link depending on what namespace you are on. I know that this crafty UI was introduced to encourage users to use the new editor. The trouble is, this assumes that users have no idea which editor they want to use, and thus will happily use whatever editor the JS can trick them into clicking. But, I suspect, most users have decided which editor they want to use before they start moving their mouse. I think users should be encouraged to use VE by making VE really awesome, and by promoting its awesomeness, rather than by trying to trick them into using it. -- Tim Starling ___ 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] Remove 'visualeditor-enable' from $wgHiddenPrefs
My apologies for the ham handed email. I'm supportive of the opt out feature while ve is in beta. Going forward I agree with the notion that experienced editors know what editor they want to use before the page completely loads. I like the idea of a preference to select a default editor. — Sent from Mailbox for iPhone On Tue, Jul 23, 2013 at 9:32 PM, Rob Moen wrote: > I personally know for a fact nobody is trying to trick the user in this case. > We are simply trying to make editing easier for new editors without > confusing them. As a membwr f the visual editor team, I'm supportive of our > advanced and seemingly more important editors opt-out during the beta. > — > Sent from Mailbox for iPhone > On Tue, Jul 23, 2013 at 21:23, Tim Starling > mailto:tstarl...@wikimedia.org";>> wrote: > On 23/07/13 04:36, Erik Moeller wrote: >> 1) Section editing behavior - the hybrid link display is mildly >> annoying, and doesn't work for touch interfaces; > I think it's a bit more than mildly annoying, and I think it's the > main reason users are so desperate to disable VE completely instead of > simply not clicking on it. > Consider it from a cognitive point of view: > Half the time (e.g. on talk pages), the section edit link will go to > the old edit page, and the other half, it will flash an "edit source" > link at you for the 100ms or so it takes to stabilise the cursor > position and execute a mouse click, and then it will launch the visual > editor. Often, the user is punished for clicking on the wrong link by > having their browser lock up for 15 seconds. > Habit formation is cleverly avoided by changing the function of the > link depending on what namespace you are on. > I know that this crafty UI was introduced to encourage users to use > the new editor. The trouble is, this assumes that users have no idea > which editor they want to use, and thus will happily use whatever > editor the JS can trick them into clicking. But, I suspect, most users > have decided which editor they want to use before they start moving > their mouse. > I think users should be encouraged to use VE by making VE really > awesome, and by promoting its awesomeness, rather than by trying to > trick them into using it. > -- Tim Starling > ___ > 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] Mark Hershberger departing Wikimedia Foundation in May
Mark, you rock! It was nice getting to know you these past few months. Sad to see you go. Take care man. On Fri, Mar 16, 2012 at 12:13 PM, Max Semenik wrote: > On 16.03.2012, 21:31 Rob wrote: > > > Hi everyone, > > > I regret to inform you all that Mark Hershberger will be leaving the > > Wikimedia Foundation at the end of May. > > Mark, thank you for everything - and may all your greener pastures be > evergreen! > > -- > Best regards, > Max Semenik ([[User:MaxSem]]) > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I'd prefer that you didn't submit this
I agree. Having 'you' or 'i' makes the message personal when the focus
should remain on the commit itself.
+ 1
This patch needs improvement. | Needs improvement, this patch does. ( if
we go with the yoda job )
On Wed, Mar 28, 2012 at 8:29 AM, Antoine Musso wrote:
> Le 28/03/12 15:10, Chad a écrit :
> > There's been some comments that the phrasing for a -1 vote in
> > Gerrit ("I'd prefer that you didn't submit this") is kind of personal
> > and we can do better.
>
> Better as make it even more personal ? :-D
>
> My suggestion is:
>
> "This patchset needs to be improved"
>
> That sounds positive to me. At least improving something is probably
> more of a reward than fixme.
>
> Sometime, we might have a patch which is fine to merge but not perfect
> yet, so I guess that case is covered by my suggestion.
>
>
> A fun one would be:
>
> "Much to learn you still have...my old padawan."
>
> Would probably make a Yoda job in Jenkins just for that :-D
>
>
> --
> Antoine "hashar" Musso
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
Rob Moen
Wikimedia Foundation
rm...@wikimedia.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)
Timo where are you ? +1 .addClass as it directly manipulates the .className property. On Aug 28, 2012, at 10:52 AM, Trevor Parscal wrote: > jQuery internally maps '' to document.createElement( 'tagName' ). > This is a feature, and is used throughout jQuery internally. It's not very > well documented as such, but Timo is adding it to the documentation as to > resolve the confusion around this. $( '' ) is a shortcut added to > jQuery for our convenience, and I think it's reasonable to use it. > > On Tue, Aug 28, 2012 at 10:44 AM, Mark Holmquist > wrote: > >> In creating elements, maybe, but after creation, $.prop() is the preferred >> way to go because the DOM properties are more reliably synced with the >> actual state of the UI--apparently jQuery doesn't always properly sync the >> HTML attributes to the browser state. I'm sure Timo can explain more fully >> (and maybe more accurately). >> > > We had this discussion yesterday, and addClass is more direct than prop( > 'className' ) in every way and unless you mean to actually replace all > existing classes, addClass is preferred. prop is there for a reason and > it's also safe to use as escaping goes, but obviously not all attributes > are actually properties, so it's not like we should stop using attr. > > - Trevor > ___ > 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] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)
On Aug 28, 2012, at 10:52 AM, Trevor Parscal wrote: > jQuery internally maps '' to document.createElement( 'tagName' ). > This is a feature, and is used throughout jQuery internally. It's not very > well documented as such, but Timo is adding it to the documentation as to > resolve the confusion around this. $( '' ) is a shortcut added to > jQuery for our convenience, and I think it's reasonable to use it. > + 1 I've always used ''. Recently though, I learned that you no longer need to do that in jQuery. And since have been using ''. > On Tue, Aug 28, 2012 at 10:44 AM, Mark Holmquist > wrote: > >> In creating elements, maybe, but after creation, $.prop() is the preferred >> way to go because the DOM properties are more reliably synced with the >> actual state of the UI--apparently jQuery doesn't always properly sync the >> HTML attributes to the browser state. I'm sure Timo can explain more fully >> (and maybe more accurately). >> > > We had this discussion yesterday, and addClass is more direct than prop( > 'className' ) in every way and unless you mean to actually replace all > existing classes, addClass is preferred. prop is there for a reason and > it's also safe to use as escaping goes, but obviously not all attributes > are actually properties, so it's not like we should stop using attr. > > - Trevor > ___ > 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] [Analytics] Welcome, Dan Andreescu!
That's awesome. I'm looking to build a Earthship home someday. Welcome to the Foundation. Rob On Sep 10, 2012, at 10:31 AM, Rob Lanphier wrote: > Hi everyone, > > I'm pleased to announce Dan Andreescu will join the Analytics team > today as our new Javascript/UI engineer. In this role, he will be > taking on development of Limn[1], our data visualization and dashboard > building toolkit. He is also going to be responsible for the > front-end for Kraken[2], the self-servicing data platform that is > being developed by the Analytics team. > > Dan studied Computer Science at Cornell University and he is a builder > at heart. He is passionate about designing and building almost > anything: furniture, software, tools and houses. An example of this > is his work with Earthship[3]: radically sustainable buildings made > with recycled materials. Clearly, Dan loves working on big problems > and that's why we are so excited to have him join the Foundation (and > the Analytics Team in particular)! > > Dan is based out of Philadelphia, and is on IRC as "milimetric". > Please join me in welcoming Dan! > > Rob > [1] https://github.com/wikimedia/limn > [2] http://www.mediawiki.org/wiki/Analytics/Kraken > [3] http://earthship.com/ > > ___ > Analytics mailing list > analyt...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/analytics ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Notification bubble system
Not sure if this is a known issue, but the notification is at the top of the
document regardless of where you are on the page. Meaning if I'm at the bottom
of a long article, I have to scroll up to the top to see the bubble. Should it
not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at the
bottom of a long article. This may have gone unnoticed as it seems mw.notify
is only triggered by UI components at the top of the page.
On Sep 18, 2012, at 5:11 PM, Jon Robson wrote:
> There is a huge usability issue with the current implementation.
> I just watched an article on commons and got a notification bubble, I then
> tried to use the down arrow to click global usage and couldn't actually get
> to the menu.
>
> I don't seem to be able to dismiss the notification.
>
> On Tue, Sep 18, 2012 at 8:07 AM, Gerard Meijssen
> wrote:
>
>> Hoi,
>> The default watchlist is 37 words ... these words are probably en.wikipedia
>> measurements. To what extend have different scripts and different languages
>> been considered ?
>> Thanks.
>> GerardM
>>
>> On 18 September 2012 00:09, Steven Walling
>> wrote:
>>
>>> On Sat, Sep 15, 2012 at 6:11 AM, Krinkle wrote:
>>>
... yes, but now that we're on the subject, lets try to aim for
standardization here instead of encouraging arbitrary HTML for layout
>>> (I'd
like to phase that out sooner rather than later). We can allow HTML
>>> inside
the body (e.g. for hyperlinks which are allowed even in edit
>> summaries),
though we could call jQuery .text() on html and disallow HTML
>> completely
(while still keeping output clean of html characters). We'll see about
>>> that
later. One step at a time.
I propose to implement the following content options (in addition to
>> the
configuration options we have like "autoHide" and "tag"). Inspired by
>> API
for Notification Center as found in OS X and iOS:
* icon (optional)
Must be square and transparent. Can potentially be displayed in
>> different
sizes. Important here to know that this icon is for source
>>> identification,
not message type. I think it is good design to keep images out of
notifications. No smilies, check marks or the like (unless the icon of
>> a
feature contains it).
* title (optional)
Title of the message. If too long, will be auto-ellipsis-ified.
* body (required)
Spans around up to 3 or 4 lines. If too long, will be
>> auto-ellipsis-ified
(in the case of a confirmation it would contain just one or two
>>> sentences,
in case of a notification of en edit it might show (part of an) edit
summary).
* buttons (optional, multi, recommendation is to use 2 buttons, not 1
>> or
3+ )
Similar to jQuery UI dialog buttons): Label text and callback function.
There can be be no two buttons with the same label. When a message has
buttons it basically becomes what would be called an "Alert" (has
>> buttons
and doesn't autohide) in "Notification Center" lingo (as opposed to
"Banner", which autohides and has no buttons). It makes sense to
automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract
>> part
of this internally, like:
var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature';
/**
* @param {mw.Title} title
* @param {Object} revision Information about revision as given by the
>>> API.
*/
Feature.prototype.editNotif = function( title, revision ) {
return mw.notify({
content: {,
icon: extPath +
>> '/modules/ext.Feature.foo/images/notify.icon.png',
title: title.getPrefixedText(),
body: $.parseHTML( revision.parsedcomment )
},
config: {
autoHide: true
});
};
>>>
>>> Following up on what I said previously about wanting to build on top of
>>> this, there are some usability enhancements proposed at bug #40307.
>>>
>>> On the truncation issue: length is already something of an issue, from my
>>> perspective. For example: the default watchlist message, which is 37
>> words,
>>> seems to have been written on the assumption that the notification
>>> container would be much wider. I've heard some complaints about it.[1]
>> I'm
>>> not sure if truncation is the correct method, but we should do something
>> to
>>> keep messages short.
>>>
>>> Steven
>>>
>>> 1. "[10:22:25] Fluffernutter: the javascript "flash" for watchlisting is
>>> driving me very slightly nuts - it lasts too long and blocks out text"
>>> https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-09-08
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>> _
Re: [Wikitech-l] Notification bubble system
On Sep 20, 2012, at 3:48 PM, Krinkle wrote: > If they happened as a direct > consequence of a user action, maybe it should appear inside the interface > where > it was performed? Agreed, interaction related notifications should be localized in the interface where the action is be performed. This increases visibility and implies a connection to the user action. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome Željko Filipin, QA Engineer
I'm very glad you are joining us Željko. Welcome!
On Oct 2, 2012, at 8:47 PM, Krinkle wrote:
> On Oct 2, 2012, at 4:25 PM, Chris McMahon wrote:
>
>> I am pleased to announce that Željko Filipin joins WMF this week as QA
>> Engineer.
>
> Welcome Željko!
>
> For the last 1.5 year, hashar and I have set up the current integration
> environment. I'm also in CET ("Krinkle" on freenode).
>
> Hashar did most of the backend with PHPUnit and Jenkins, I'm occupied in
> browsers and unit testing their in (QUnit/TestSwarm/BrowserStack/..).
>
> Looking forward to work with you!
>
> --
> Timo "Krinkle" Tijhof
>
>
> ___
> 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] Small-ish gadget project: Bug update gadget
I started making this but then I realized I was going to have issues making the needed cross-domain post requests. I found BugTender achieved this by routing requests through it's own proxy.php script. Here is what I have so far: http://www.mediawiki.org/wiki/User:Robmoen/bugStatusUpdate.js Any thoughts for a work around ? ~Rob On Fri, Dec 30, 2011 at 12:17 PM, Erik Moeller wrote: > Hi all, > > in the new tradition of posting little gadget ideas and requests here: > > > http://www.mediawiki.org/wiki/Gadget_kitchen/Requests#Automatic_updates_to_pages_with_bug_templates > > This would be helpful for pages which use bug templates like > [[mw:Template:Tracked]] to inform users about the status of bugs they > care about. If it's useful and efficient, we could promote it to > default gadget or site script. > > Any takers? :) > > Cheers, > Erik > > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate > > ___ > 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] Small-ish gadget project: Bug update gadget
I have updated this to use jsonp get requests with jQuery. Here is a link to the gadget: http://www.mediawiki.org/wiki/User:Robmoen/bugStatusUpdate.js Once activated, it's use can be demoed here: http://www.mediawiki.org/wiki/User_talk:Robmoen I fiddled with the request parameters for a while trying to get the JSON RPC to not throw errors. I settled with a URL request for now which is working nicely. Feel free to shoot me ideas / thoughts on how this could be improved. Rob On Fri, Dec 30, 2011 at 7:01 PM, Erik Moeller wrote: > On Fri, Dec 30, 2011 at 5:15 PM, Rob Moen wrote: > > I started making this but then I realized I was going to have issues > making > > the needed cross-domain post requests. > > I found BugTender achieved this by routing requests through it's own > > proxy.php script. > > > > Here is what I have so far: > > http://www.mediawiki.org/wiki/User:Robmoen/bugStatusUpdate.js > > Got it to work using JSONP GET requests. Leaving a note on your talk > page with more details. > > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Small-ish gadget project: Bug update gadget
Very cool. Nice work Mark! On Wed, Jan 11, 2012 at 9:10 PM, Mark A. Hershberger < mhershber...@wikimedia.org> wrote: > mhershber...@wikimedia.org (Mark A. Hershberger) writes: > > > Rob Moen writes: > > > >> I fiddled with the request parameters for a while trying to get the JSON > >> RPC to not throw errors. I settled with a URL request for now which is > >> working nicely. > >> Feel free to shoot me ideas / thoughts on how this could be improved. > > > > I can think of all sorts of ways to improve this. I may take a crack > > at it soon. > > You can see my "improvements" here: > http://labs.wikimedia.deployment.wmflabs.org/wiki/Problem_reports > > (Following up here even though I mentioned it in another email because > that one may have be TL;DR for some people.) > > Mark. > -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator migration update
On Fri, Jul 18, 2014 at 3:29 PM, Steven Walling wrote: > That said, I think Growth would be interested in provisionally > giving Phabricator a try as a Trello/Bugzilla replacement. > +1 -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Stance on Social Media
Currently our approach on social media is that "Social media websites aren't useful for spreading news and reaching out to potential users and contributors." [1] I challenge this though. Is it really true? Twitter has 254 million active monthly users, with 500 million tweets sent per day [2], Facebook has 1.35 billion active monthly users users. [3] I know there are many active Wikipedians who frequent both of these sites. Should we be more actively encouraging people to share? The history of the Social Media page indicates this was added as an ‘initial dump’ back in November of 2011. [4] But I wonder if it might be worth revisiting or refreshing this decision in light of the current world we live in. What do others think? What would the reaction be to a sharethis.com type service where any site could engage ? Would this be more valuable on mobile than than desktop? 1: https://www.mediawiki.org/wiki/Social_media 2: https://about.twitter.com/company 3: http://newsroom.fb.com/company-info 4: https://www.mediawiki.org/w/index.php?title=Social_media&diff=1318877&oldid=458857 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
