Re: [Wikitech-l] Why are we still using captchas on WMF sites?
On 22/01/13 18:43, David Gerard wrote: On 22 January 2013 17:37, vita...@yourcmc.ru wrote: Per the previous comments in this post, anything over 1% precision should be regarded as failure, and our Fancy Captcha was at 25% a year ago. So yeah, approximately all, and our captcha is well known to actually suck. Maybe you'll just use recaptcha instead of fancycaptcha? The problem is that reCaptcha (a) used as a service, would pass private user data to a third party (b) is closed source, so we can' t just put up our own instance. Has anyone reimplemented it or any of it? There's piles of stuff on Wikisource we could feed it, for example. http://wikimania2012.wikimedia.org/wiki/Submissions/Wikicaptcha:_a_ReCAPTCHA-like_solution_for_Wikisource https://github.com/CristianCantoro/wikicaptcha I don't know what ultimately came of it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Why are we still using captchas on WMF sites?
Luke, we do not know how many humans are being turned away by the difficulty: actually we sort of do, that paper tells this as well. It's where their study came from, and gives recommendations on what captcha techniques are best for balancing efficacy with difficulty for humans. We don't seem to be following any (except waving, which, they say, shouldn't be used alone). Then, I'm not qualified to say if their recommendations are the best and I've not searched other studies, but it's not correct to say that we start from zero or that we have to study by ourselves (an unreasonable requirement that implies we'll never change anything until we'll be forced to make our wikis read-only due to spam, as many MediaWiki users before us). Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
(anonymous) wrote: [...] Really, we should be using them in the footer so gerrit can track them. Eg: === Some awesome new feature Blah blah blah I did stuff Fixed this too. Bug: 1234 Change-Id: I === This should be Fixes-Bug: or something similar (I'll leave it to the native speakers whether Bug-Fix:, Fixed-Bug:, or something else is best at corresponding to Change-Id:). Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
Whenever a file is linked to with a size specification, e.g. [[File:test.png|thumb|123px]], a new thumbnail is generated in that particular size, and saved to the disk. This is generally a good thing, because it minimises the amount of data the clients need to download without losing quality at that display size. However, this is also an avenue for denial of service - someone could create many links to different images with non-standard sizes, intentionally or unintentionally, and therefore overload computational (temporarily) and storage resources on the server. Therefore, I propose an option which would either limit the number of stored/generated thumbnails or limit their sizes to a particular set (e.g. powers of two) - however, this should not come at a loss of functionality. Whenever an image link requests a size which can't be generated, for whatever reason, either the next-largest or the next-smallest image is sent, with relevant CSS styles to resize it in the browser. The decision between next-largest and next-smallest would be governed by a user-preferences option which would default to 25% i.e. send the smaller image if the larger image is at least 75% larger than the target size (this should probably use the thumbnail area for comparisons rather than the width, if it's not a major performance hit). This proposal is especially important for public deployments with large amounts of (especially non-technical) users and/or tight limits on disk space. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html comments into raw wiki code: can they be wrapped into parsed html?
In the meantime, I tested the urlencode:...|WIKI trick, it runs perfectly for quotes, html tags as br / and links wikicode. Now it can be used both for tl|Autore and tl|Intestazione into it.wikisource, and I hope into tl|MediaWiki:Proofreadpage_index_template too. But it fails with templates; templates passed as a parameter are parsed before urlencode can do its masking job. See [[:commons:User:Alex brollo/Sandbox]] for my test, which uses an instance of a modified tl|Book (my interest is focused to Book and Creator templates). Presently my way for data recovering is a simple AJAX query but as an ecologist I'd like to save both band and server load. :-) Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
I would advise against doing anything with the word Fix in it, because a commit does not necessarily fix a bug. It's possible that a fix for a bug spans multiple commits, depending on the scope of the bug. When you do just Bug, all it implies is that you can see that bug report for related information and discussion on the commit. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jan 23, 2013 at 3:57 AM, Tim Landscheidt t...@tim-landscheidt.dewrote: (anonymous) wrote: [...] Really, we should be using them in the footer so gerrit can track them. Eg: === Some awesome new feature Blah blah blah I did stuff Fixed this too. Bug: 1234 Change-Id: I === This should be Fixes-Bug: or something similar (I'll leave it to the native speakers whether Bug-Fix:, Fixed-Bug:, or something else is best at corresponding to Change-Id:). Tim ___ 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] Html comments into raw wiki code: can they be wrapped into parsed html?
It definitely needs a redesign or a different approach. I believe that putting rendered view into data attributes is the worst practice ever. Data is for data, and if you want to put rendering onto client's shoulders (that is why you want these data attributes, right?), then you should not mix client- and server-site together. On Wed, Jan 23, 2013 at 4:46 PM, Alex Brollo alex.bro...@gmail.com wrote: In the meantime, I tested the urlencode:...|WIKI trick, it runs perfectly for quotes, html tags as br / and links wikicode. Now it can be used both for tl|Autore and tl|Intestazione into it.wikisource, and I hope into tl|MediaWiki:Proofreadpage_index_template too. But it fails with templates; templates passed as a parameter are parsed before urlencode can do its masking job. See [[:commons:User:Alex brollo/Sandbox]] for my test, which uses an instance of a modified tl|Book (my interest is focused to Book and Creator templates). Presently my way for data recovering is a simple AJAX query but as an ecologist I'd like to save both band and server load. :-) Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html comments into raw wiki code: can they be wrapped into parsed html?
2013/1/23 Paul Selitskas p.selits...@gmail.com It definitely needs a redesign or a different approach. I believe that putting rendered view into data attributes is the worst practice ever. Data is for data, and if you want to put rendering onto client's shoulders (that is why you want these data attributes, right?), then you should not mix client- and server-site together. No, I don't at all. I only need to get clean parameters value wrapped into rendered page, so avoiding a difficult (sometimes, impossible) reverse engineering to get them, and avoiding an AJAX call to get them as-they-are. I see Infoboxes as potentially excellent records where data are impossible to read and use (for a large variety of interesting uses); and I think that's a pity and someway a resource-wasting situation. Rendering is only one of dozens of possible uses - but no data, no use of data. The whole thing is very simple and effective is infobox template code is designed from the beginning to accept clean string data without any wikicode or html code inside; but I see that very few infoboxes are designed to get such clean data and nothing other. Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
On 23 January 2013 13:24, Georgiy Tugai georgiy.tu...@gmail.com wrote: However, this is also an avenue for denial of service - someone could create many links to different images with non-standard sizes, intentionally or unintentionally, and therefore overload computational (temporarily) and storage resources on the server. Note that this has been debated at least a few times in the past. See e.g. the thread at http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/63701/ -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Why are we still using captchas on WMF sites?
I don't know if we are talking at cross purposes, or if I missed it, but this paper: http://elie.im/publication/text-based-captcha-strengths-and-weaknesses does not try to answer my question. What I want to know is *How many humans get turned away from editing Wikipedia by a difficult captcha?* The same authors have: http://elie.im/publication/how-good-are-humans-at-solving-captchas-a-large-scale-evaluation which is closer to what I want to know. They show humans solving different text based captures with an accuracy rate of 70% to 98%. Unfortunately, Wikipedia was not one of the captcha schemes they used in that study, and they don't attempt to measure how many people try again if they fail. If 2% of people fail on the first try but 90% of the fails reattempt and only 1% fail a second time that's an inconvenience, but probably worth it if it reduces the inconvenience of spam. If 30% of people fail on the first try and 90% of them give up and never try to edit again, that's a disaster. Luke On Wed, Jan 23, 2013 at 12:24 AM, Federico Leva (Nemo) nemow...@gmail.comwrote: Luke, we do not know how many humans are being turned away by the difficulty: actually we sort of do, that paper tells this as well. It's where their study came from, and gives recommendations on what captcha techniques are best for balancing efficacy with difficulty for humans. We don't seem to be following any (except waving, which, they say, shouldn't be used alone). Then, I'm not qualified to say if their recommendations are the best and I've not searched other studies, but it's not correct to say that we start from zero or that we have to study by ourselves (an unreasonable requirement that implies we'll never change anything until we'll be forced to make our wikis read-only due to spam, as many MediaWiki users before us). Nemo __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Naming our developer events
Hi, back in November Erik and Sumana explained the intention of the WMF to get less involved in the direct organization of developer events. Instead, the WMF will empower and help community groups taking the lead organizing developer activities. http://lists.wikimedia.org/pipermail/wikimedia-l/2012-November/122725.html In practice, this means that those events are run more in a franchise-like mode (sorry for the commercial word: I'm using it to illustrate the point). As we can learn from the franchise model, the more complete is the documentation and the more standardized is the process, the easier it is for a local promoter to setup and activity on their own and succeed. Local successes help the global success, and global success helps local successes. Ok, now back to our reality. :) The first element of an event is its name, and already there we have room for improvement. Proposal: naming all our developer events MediaWiki Hackathon City e.g. MediaWiki Hackathon Amsterdam, to mention an event currently showing a branding problem: https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 Localizations and exceptions to be considered and approved one by one. The problem, in more detail: - We seem to have an erratic use of Wikipedia, Wikimedia, MediaWiki, [choose your logo] and [nothing] for naming these events. For instance, see the web pages of San Francisco Hackathon Berlin Hackathon or Amsterdam Hackathon and try to find the full name written down. The pictures show that creative, inconsistent solutions were found for the banners. This makes no sense for the outsiders we want to reach. - We seem to use Hackathon always but then Bangalore was a DevCamp. It is useful to settle in one word, unless the event is something completely different. - Some events specify the date in their name, some don't. There is no need to specify the month-year in the name of the event since any event has a date anyway. This allows us to recycle and update web pages, archiving properly past events. URLs stay and they become stronger. You can find an extreme example of this problem in Wikimania where (up to date) every year there has been a new URL, a new Twitter account, etc. Let's avoid this problem at least in our context. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
On 01/23/2013 12:14 PM, Quim Gil wrote: Hi, back in November Erik and Sumana explained the intention of the WMF to get less involved in the direct organization of developer events. Instead, the WMF will empower and help community groups taking the lead organizing developer activities. http://lists.wikimedia.org/pipermail/wikimedia-l/2012-November/122725.html In practice, this means that those events are run more in a franchise-like mode (sorry for the commercial word: I'm using it to illustrate the point). As we can learn from the franchise model, the more complete is the documentation and the more standardized is the process, the easier it is for a local promoter to setup and activity on their own and succeed. Local successes help the global success, and global success helps local successes. Ok, now back to our reality. :) The first element of an event is its name, and already there we have room for improvement. Proposal: naming all our developer events MediaWiki Hackathon City e.g. MediaWiki Hackathon Amsterdam, to mention an event currently showing a branding problem: https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 Localizations and exceptions to be considered and approved one by one. The problem, in more detail: - We seem to have an erratic use of Wikipedia, Wikimedia, MediaWiki, [choose your logo] and [nothing] for naming these events. For instance, see the web pages of San Francisco Hackathon Berlin Hackathon or Amsterdam Hackathon and try to find the full name written down. The pictures show that creative, inconsistent solutions were found for the banners. This makes no sense for the outsiders we want to reach. - We seem to use Hackathon always but then Bangalore was a DevCamp. It is useful to settle in one word, unless the event is something completely different. - Some events specify the date in their name, some don't. There is no need to specify the month-year in the name of the event since any event has a date anyway. This allows us to recycle and update web pages, archiving properly past events. URLs stay and they become stronger. You can find an extreme example of this problem in Wikimania where (up to date) every year there has been a new URL, a new Twitter account, etc. Let's avoid this problem at least in our context. I am actually fine with inconsistency here. I don't think we need uniformity. In one city, local technologists might call something a hackathon; in another country, the word hack always means cracking and security work, so the people we want to reach would understand better if we call it a training or a conference or a jam or dev days; and so on. (This is what has happened in India and caused actual headaches and disappointment and misleading word-of-mouth for past Indian events that had hack in the name.) I'd like to see what the actual harm caused by inconsistency is and I'd like more data on what real benefit we'd get by making people always name things according to the same scheme. Not just hypotheticals. Perhaps a few other open source communities have dealt with this and would be able to provide that data. Dates in the names of events -- sure, do away with those, fine. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
I felt the last conversation stalled due to a lack of data and lots of speculation. It would be great if someone in the analytics team could give an idea of the most commonly requested thumbnails and we could use this as the basis for a new conversation. I'd suggest that once we have such a list we standardise on several sizes and deprecate the others - returning the closest size match for those and leaving it to css/width and height attributes to perform the scaling wanted. On Wed, Jan 23, 2013 at 8:25 AM, Petr Kadlec petr.kad...@gmail.com wrote: On 23 January 2013 13:24, Georgiy Tugai georgiy.tu...@gmail.com wrote: However, this is also an avenue for denial of service - someone could create many links to different images with non-standard sizes, intentionally or unintentionally, and therefore overload computational (temporarily) and storage resources on the server. Note that this has been debated at least a few times in the past. See e.g. the thread at http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/63701/ -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
Quim, Responses inline. - We seem to have an erratic use of Wikipedia, Wikimedia, MediaWiki, [choose your logo] and [nothing] for naming these events. For instance, see the web pages of San Francisco Hackathon Berlin Hackathon or Amsterdam Hackathon and try to find the full name written down. The pictures show that creative, inconsistent solutions were found for the banners. This makes no sense for the outsiders we want to reach. +1 for standardizing to Mediawiki event city - We seem to use Hackathon always but then Bangalore was a DevCamp. It is useful to settle in one word, unless the event is something completely different. We changed the usage of the term 'hackathon' to 'devcamp' specifically for the India subcontinent where 'hacking=security breakins'. We were having to turnaway people who wanted to work together on cracking passwords and more at our hackathons. The preferred terminology in Asia would not be 'hackathon'. Devcamps have also included lightning talks as well as tutorials and demos. Again, localizing for the needs of a geography is okay. - Some events specify the date in their name, some don't. There is no need to specify the month-year in the name of the event since any event has a date anyway. This allows us to recycle and update web pages, archiving properly past events. URLs stay and they become stronger. You can find an extreme example of this problem in Wikimania where (up to date) every year there has been a new URL, a new Twitter account, etc. Let's avoid this problem at least in our context. I agree. There is no need to specify month-year in the event name. We discarded the practice for the most recent Bangalore DevCamp. -Alolita On Wed, Jan 23, 2013 at 9:21 AM, Sumana Harihareswara suma...@wikimedia.org wrote: On 01/23/2013 12:14 PM, Quim Gil wrote: Hi, back in November Erik and Sumana explained the intention of the WMF to get less involved in the direct organization of developer events. Instead, the WMF will empower and help community groups taking the lead organizing developer activities. http://lists.wikimedia.org/pipermail/wikimedia-l/2012-November/122725.html In practice, this means that those events are run more in a franchise-like mode (sorry for the commercial word: I'm using it to illustrate the point). As we can learn from the franchise model, the more complete is the documentation and the more standardized is the process, the easier it is for a local promoter to setup and activity on their own and succeed. Local successes help the global success, and global success helps local successes. Ok, now back to our reality. :) The first element of an event is its name, and already there we have room for improvement. Proposal: naming all our developer events MediaWiki Hackathon City e.g. MediaWiki Hackathon Amsterdam, to mention an event currently showing a branding problem: https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 Localizations and exceptions to be considered and approved one by one. The problem, in more detail: - We seem to have an erratic use of Wikipedia, Wikimedia, MediaWiki, [choose your logo] and [nothing] for naming these events. For instance, see the web pages of San Francisco Hackathon Berlin Hackathon or Amsterdam Hackathon and try to find the full name written down. The pictures show that creative, inconsistent solutions were found for the banners. This makes no sense for the outsiders we want to reach. - We seem to use Hackathon always but then Bangalore was a DevCamp. It is useful to settle in one word, unless the event is something completely different. - Some events specify the date in their name, some don't. There is no need to specify the month-year in the name of the event since any event has a date anyway. This allows us to recycle and update web pages, archiving properly past events. URLs stay and they become stronger. You can find an extreme example of this problem in Wikimania where (up to date) every year there has been a new URL, a new Twitter account, etc. Let's avoid this problem at least in our context. I am actually fine with inconsistency here. I don't think we need uniformity. In one city, local technologists might call something a hackathon; in another country, the word hack always means cracking and security work, so the people we want to reach would understand better if we call it a training or a conference or a jam or dev days; and so on. (This is what has happened in India and caused actual headaches and disappointment and misleading word-of-mouth for past Indian events that had hack in the name.) I'd like to see what the actual harm caused by inconsistency is and I'd like more data on what real benefit we'd get by making people always name things according to the same scheme. Not just hypotheticals. Perhaps a few other open source communities have dealt with this and would be able to
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
Tyler Romeo tylerro...@gmail.com wrote: I would advise against doing anything with the word Fix in it, because a commit does not necessarily fix a bug. It's possible that a fix for a bug spans multiple commits, depending on the scope of the bug. When you do just Bug, all it implies is that you can see that bug report for related information and discussion on the commit. [...] Then why would you use Fixes: 123 if the commit doesn't actually fix bug #123? Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
+1 for not forcing a standard on. (Talking from the perspective of organizing smaller events) If we standardize on 'Hackathon', we'll have people coming in and asking us 'how to crack fb?'. If we call it 'Workshop', we'll have people coming in asking for certificates (or wondering how much to pay for it). DevCamp avoids these problems by being completely ambiguous :P Every event needs associated messaging to reach the right audience and to set the right expectations. Workshops and hackathons are also fundamentally different events - Workshops are 1 to many knowledge transfer + hacking, while hackathons are much more distributed 'get stuff done' type things. Without proper messaging, people might come expecting the former, and be disappointed to get the latter (or vice versa). Forcing a convention would make the problem worse. TL;DR: -1 to standardizing for names, let whoever is organizing it figure it out. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] An actual bikeshed
Hi, There's been a lot of bikeshedding topics recently. On things ranging from spaces, to typos, to naming things. I was kind of tired of these mundane threads, so I decided to start one on something productive. What color should the bikeshed be? I vote blue. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
(ex)Gerrit Green. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
Wadler's law will always hold. :P *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jan 23, 2013 at 1:11 PM, Chad innocentkil...@gmail.com wrote: Hi, There's been a lot of bikeshedding topics recently. On things ranging from spaces, to typos, to naming things. I was kind of tired of these mundane threads, so I decided to start one on something productive. What color should the bikeshed be? I vote blue. -Chad ___ 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] An actual bikeshed
On Wed, Jan 23, 2013 at 10:11 AM, Chad innocentkil...@gmail.com wrote: Hi, There's been a lot of bikeshedding topics recently. On things ranging from spaces, to typos, to naming things. I was kind of tired of these mundane threads, so I decided to start one on something productive. What color should the bikeshed be? I vote blue. Trick question: there is no bikeshed. It is only your mind that bends. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix bug 123. However, what if there's a case like I said, where a bug is fixed across multiple commits. If you're using the Fixes tag, then technically you should only be tagging the last commit that finally fixes the bug, in which case all the other commits are left unmarked and are lost in the repository. With just a Bug tag, it indicates that the commit is related to the bug. My reasoning has to do with the motivation behind why we tag commits. Maybe I'm wrong, but the reason we tag commits with bug numbers is so that, in the future, if one wants to find the commit(s) that fixed a certain bug, they can do a quick grep search on the commit log and find the relevant commits. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jan 23, 2013 at 1:04 PM, Tim Landscheidt t...@tim-landscheidt.dewrote: Tyler Romeo tylerro...@gmail.com wrote: I would advise against doing anything with the word Fix in it, because a commit does not necessarily fix a bug. It's possible that a fix for a bug spans multiple commits, depending on the scope of the bug. When you do just Bug, all it implies is that you can see that bug report for related information and discussion on the commit. [...] Then why would you use Fixes: 123 if the commit doesn't actually fix bug #123? Tim ___ 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] The ultimate bikeshed: typos in commit messages
On Wed, Jan 23, 2013 at 1:17 PM, Tyler Romeo tylerro...@gmail.com wrote: My reasoning has to do with the motivation behind why we tag commits. Maybe I'm wrong, but the reason we tag commits with bug numbers is so that, in the future, if one wants to find the commit(s) that fixed a certain bug, they can do a quick grep search on the commit log and find the relevant commits. It's even easier than that: https://gerrit.wikimedia.org/r/#/q/bug:43523,n,z Gerrit indexes these values, so you can search for bug:123 or rt:456. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
(It would be good to have the opinion of the http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 organizers here) On 01/23/2013 09:21 AM, Sumana Harihareswara wrote: I am actually fine with inconsistency here. I think you mean you are fine with flexibility. Me too. :) I don't think we need uniformity. Me neither. I'm proposing defaults and flexibility to change them based on need. Now we have lack of defaults, which leads to confusion and extra work. In one city, local technologists might call something a hackathon; in another country, the word hack always means cracking and security work, so the people we want to reach would understand better if we call it a training or a conference or a jam or dev days; and so on. (This is what has happened in India and caused actual headaches and disappointment and misleading word-of-mouth for past Indian events that had hack in the name.) This would fall under Localizations and exceptions to be considered and approved one by one. If we find useful rules like in India DevCamp is better than Hackathon then we can just document and apply them. Problem solved. But the hackathon part is easy. The nut hard to crack is the Wikipedia, Wikimedia, MediaWiki, [choose your logo] and [nothing]. If you and me can have doubts, imagine the poor local event organizer somewhere. Can we agree on a default? I'd like to see what the actual harm caused by inconsistency is and I'd like more data on what real benefit we'd get by making people always name things according to the same scheme. Not just hypotheticals. No harm... but no help either. Whoever wants to organize a hackathon today must start almost from scratch and doing some research because there are not clear precedents and recyclable materials. Imagine yourself willing to have a hackathon in NY: - How to call it? - Do I need to craft my own logo? Which imply: Who to ask permission? Before having this clear it's not easy to even setup a wiki page or send a first email or tweet announcing that you are planning to organize such event. For WMF employees and others deeply involved in this community this might not be a good deal. But for your local tech promoter this lack of clarity it really doesn't help. Those are exactly the ones we want to engage. Perhaps a few other open source communities have dealt with this and would be able to provide that data. Looking at e.g. the Mozilla and Ubuntu communities you can see that they have defaults (MozCamps, Firefox OS App Days, Ubuntu Hours, UDS, LoCo meetings... and flexibility for alternatives as well. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
On Wed, Jan 23, 2013 at 9:14 AM, Quim Gil q...@wikimedia.org wrote: MediaWiki Hackathon City As a team that doesn't exclusively work within MediaWiki what would you suggest for naming if someone wanted to run a hackathon on our mobile apps? Our mobile apps are fully decoupled from mw and only use its API. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
On 01/23/2013 01:11 PM, Chad wrote: Hi, There's been a lot of bikeshedding topics recently. On things ranging from spaces, to typos, to naming things. I was kind of tired of these mundane threads, so I decided to start one on something productive. What color should the bikeshed be? I vote blue. -Chad Bohemian-bourgeois answer: The organic free-range sustainable sweatshop-free paint only comes in mauve. Too Much Monty Python answer: Blue! No, green! Auggghh! https://www.youtube.com/watch?v=pWS8Mg-JWSg Community manager's dream answer: Here's a bunch of paint and some brushes, go have fun! [time passes] Oh what a lovely mural! -Sumana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
Tomasz has a good point. Language tools and apps don't use Mediawiki exclusively either. This is one of the reasons we used Wikipedia Engineering instead of Mediawiki for our Bangalore DevCamp naming. -Alolita On Wed, Jan 23, 2013 at 10:37 AM, Tomasz Finc tf...@wikimedia.org wrote: On Wed, Jan 23, 2013 at 9:14 AM, Quim Gil q...@wikimedia.org wrote: MediaWiki Hackathon City As a team that doesn't exclusively work within MediaWiki what would you suggest for naming if someone wanted to run a hackathon on our mobile apps? Our mobile apps are fully decoupled from mw and only use its API. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Alolita Sharma Director of Engineering Language Engineering Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
Hey, What color should the bikeshed be? I'll forgive you for your ignorance - one really needs to start with picking the kind of paint first Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
On Wed, Jan 23, 2013 at 11:57 PM, Quim Gil q...@wikimedia.org wrote: Looking at e.g. the Mozilla and Ubuntu communities you can see that they have defaults (MozCamps, Firefox OS App Days, Ubuntu Hours, UDS, LoCo meetings... and flexibility for alternatives as well. Another relevant example would be The Fedora Project. There are Fedora Activity Days and, then there are events like FUDCon - there exist documentation on the wiki about how the events are named and handled. -- sankarshan mukhopadhyay https://twitter.com/#!/sankarshan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
Are we just appropriating a random bikeshed somewhere in SF for this project? On Wed, Jan 23, 2013 at 10:47 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, What color should the bikeshed be? I'll forgive you for your ignorance - one really needs to start with picking the kind of paint first Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- ~Matt Walker ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
It's actually a bus, not a bikeshed. It is already painted. And vim is obviously the better editor. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
If an event is specific to a piece of software then by all means let's call it after such piece of software e.g. Wikipedia Mobile Hackathon (or DevCamp, if we decide that is a better default than Hackathon) On 01/23/2013 10:46 AM, Alolita Sharma wrote: Tomasz has a good point. Language tools and apps don't use Mediawiki exclusively either. This is one of the reasons we used Wikipedia Engineering instead of Mediawiki for our Bangalore DevCamp naming. It is easy for WMF teams to organize events containing the Wikipedia word. Less so for your average local promoter. This is one practical reason to default to MediaWiki and then be flexible with exceptions. But there is another point here, which is how narrowed / inclusive are we with the MediaWiki word. You can see it as the name of a CMS. You can see it as a name of a wider community. Looking at the content at mediawiki.org it is obvious that such community does a lot more things than developing a CMS. Why not calling all those things under the MediaWiki umbrella, and refer to the CMS as MediaWiki Core? We know that Wikipedia / Wikimedia / MediaWiki confuses people systematically. Also the people attending our technical events. Simplifying might be inaccurate for some oldtimers, but it can be helpful for most of the newcomers we aim to reach out with these events. -Alolita On Wed, Jan 23, 2013 at 10:37 AM, Tomasz Finc tf...@wikimedia.org wrote: On Wed, Jan 23, 2013 at 9:14 AM, Quim Gil q...@wikimedia.org wrote: MediaWiki Hackathon City As a team that doesn't exclusively work within MediaWiki what would you suggest for naming if someone wanted to run a hackathon on our mobile apps? Our mobile apps are fully decoupled from mw and only use its API. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
Blue, and bigger on the inside. On Wed, Jan 23, 2013 at 6:57 PM, Yuvi Panda yuvipa...@gmail.com wrote: It's actually a bus, not a bikeshed. It is already painted. And vim is obviously the better editor. ___ 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] The ultimate bikeshed: typos in commit messages
Tyler Romeo tylerro...@gmail.com wrote: That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix bug 123. However, what if there's a case like I said, where a bug is fixed across multiple commits. If you're using the Fixes tag, then technically you should only be tagging the last commit that finally fixes the bug, in which case all the other commits are left unmarked and are lost in the repository. With just a Bug tag, it indicates that the commit is related to the bug. Then use Relates-To: for the relationships, and Fixes: for the fixes. My reasoning has to do with the motivation behind why we tag commits. Maybe I'm wrong, but the reason we tag commits with bug numbers is so that, in the future, if one wants to find the commit(s) that fixed a certain bug, they can do a quick grep search on the commit log and find the relevant commits. [...] I don't agree with that. There are lots of bugs that get fixed unknowingly because most of the 5034 bugs are not on the developers' radar. So any (consistent) information on which commit has fixed a bug must be kept in Bugzilla as we can't change Git's history, and it's hard to imagine a case where you want to know which commit(s) fixed bug x without looking at Bugzilla's page on bug x. IMHO the primary motivation for using Fixes: 123 (or Relates-To: 123) is to absolve the committer from te- diously going back to the Bugzilla page and adding a Gerrit link and (in the former case) the merger from marking the bug as resolved as computers are so *much* better at that (and cheaper). Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
I mean does it have to be a bike shed or can I put my boat in it? On a more serious note, I think all this bikeshedding reveals a big problem we have. It is very hard to reach consensus on many topics and it seems one person saying no has more weight than 10 people say yes. Bikeshedding prevents: * more interesting discussions about how we can improve the security of the bikeshed * can be deflating - giving the sense that the bike shed will never actually be painted, will never actually exist and I will never buy a bike and never go on wonderful bike rides. * can put people off who see that other community projects already have a painted bikeshed that is more interesting and worthy of attention * can cause broken windows - since everyone is discussing the bikeshed no one is paying attention to all the bricks some kids are throwing through the windows at night and the whole of the community centre is falling apart. Also this becomes infectious and other kids start adding graffiti to walls (well there are already broken windows) Suggested solution: Maybe some kind of voting system might be of use to force some kind of consensus rather than leaving problems unsolved. I'm fed up of receiving emails about the same problem I discussed weeks before that never got solved. It makes my mailbox ill. I mean if the question is really what colour is the bikeshed it would be good for people to propose colours, people to vote on preferred colours and at the end of say a week the majority colour wins and gets implemented (or in cases where there is no majority we discuss the front runners and other possible solutions). On Wed, Jan 23, 2013 at 11:19 AM, Magnus Manske magnusman...@googlemail.com wrote: Blue, and bigger on the inside. On Wed, Jan 23, 2013 at 6:57 PM, Yuvi Panda yuvipa...@gmail.com wrote: It's actually a bus, not a bikeshed. It is already painted. And vim is obviously the better editor. ___ 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 -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
IMHO the primary motivation for using Fixes: 123 (or Relates-To: 123) is to absolve the committer from te- diously going back to the Bugzilla page and adding a Gerrit link and (in the former case) the merger from marking the bug as resolved as computers are so *much* better at that (and cheaper). Can't we just use Gerrit's builtin topics for that? *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jan 23, 2013 at 2:28 PM, Tim Landscheidt t...@tim-landscheidt.dewrote: Tyler Romeo tylerro...@gmail.com wrote: That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix bug 123. However, what if there's a case like I said, where a bug is fixed across multiple commits. If you're using the Fixes tag, then technically you should only be tagging the last commit that finally fixes the bug, in which case all the other commits are left unmarked and are lost in the repository. With just a Bug tag, it indicates that the commit is related to the bug. Then use Relates-To: for the relationships, and Fixes: for the fixes. My reasoning has to do with the motivation behind why we tag commits. Maybe I'm wrong, but the reason we tag commits with bug numbers is so that, in the future, if one wants to find the commit(s) that fixed a certain bug, they can do a quick grep search on the commit log and find the relevant commits. [...] I don't agree with that. There are lots of bugs that get fixed unknowingly because most of the 5034 bugs are not on the developers' radar. So any (consistent) information on which commit has fixed a bug must be kept in Bugzilla as we can't change Git's history, and it's hard to imagine a case where you want to know which commit(s) fixed bug x without looking at Bugzilla's page on bug x. IMHO the primary motivation for using Fixes: 123 (or Relates-To: 123) is to absolve the committer from te- diously going back to the Bugzilla page and adding a Gerrit link and (in the former case) the merger from marking the bug as resolved as computers are so *much* better at that (and cheaper). Tim ___ 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] An actual bikeshed
On 2013-01-23 3:38 PM, Jon Robson jdlrob...@gmail.com wrote: Suggested solution: Maybe some kind of voting system might be of use to force some kind of consensus rather than leaving problems unsolved. I'm fed up of receiving emails about the same problem I discussed weeks before that never got solved. It makes my mailbox ill. I mean if the question is really what colour is the bikeshed it would be good for people to propose colours, people to vote on preferred colours and at the end of say a week the majority colour wins and gets implemented (or in cases where there is no majority we discuss the front runners and other possible solutions). What colour should the polling booth be? I don't think the answer is voting. Perhaps there are some sheds that don't need to be painted. -bawolff P.s. if someone built a bikeshed in the wmf office they would be my hero ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
Tyler Romeo tylerro...@gmail.com wrote: IMHO the primary motivation for using Fixes: 123 (or Relates-To: 123) is to absolve the committer from te- diously going back to the Bugzilla page and adding a Gerrit link and (in the former case) the merger from marking the bug as resolved as computers are so *much* better at that (and cheaper). Can't we just use Gerrit's builtin topics for that? That would actually be a very cool solution. The downside would be that the bug wouldn't be mentioned in the commit message without explicit action by the author as the topic branch is lost on merge (CMIIW), and an author would have to remember when he decides to fix a bug not in one go, but with intermediate steps, to rename the branch before submit- ting. Also, we would be limited to this one application. Other projects seem to expand the footer syntax further, cf. http://wiki.openstack.org/GerritWorkflow#Committing_Changes: | Adds keystone support | ...Long multiline description of the change... | Implements: blueprint authentication | Fixes: bug #123456 | Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657 Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
I'd strongly suggest considering this kind of approach. -- View this message in context: http://wikimedia.7.n6.nabble.com/Limiting-storage-generation-of-thumbnails-without-loss-of-functionality-tp4994447p4994493.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A testing bug management wheel
This proposal got a basic agreement and is being implemented at https://www.mediawiki.org/wiki/QA/Weekly_goals A rough start is expected in the first iteration of the four areas but we hope to have improvements every week. Get involved! Development teams: your proposals for testing bug management weekly goals are welcome. On 01/16/2013 02:25 PM, Quim Gil wrote: There are ongoing separate discussions about the best way to organize testing sprints and bug days. The more we talk and the more we delay the beginning of continuous activities the more I believe the solution is common for both: Smaller activities and more frequent. Each one of them less ambitious but more precise. Not requiring by default the involvement of developer teams. Especially not requiring the involvement of WMF dev teams. Of course we want to work together with development teams! But just not wait for them. They tend to be busy, willing and at the same time unwilling (a problem we need to solve but not necessarily before starting a routine of testing and bug management activities. If a dev team (WMF or not) wants to have dedicated testing and bug management activities we will give them the top priority. Imagine this wheel: Week 1: manual testing (Chris) Week 2: fresh bugs (Andre) Week 3: browser testing (Željko) Week 4: rotten bugs (Valerie) All the better if there is certain correlation between testing and bugs activities, but no problem if there is none. From the point of view of the week coordinators this is how a cycle would look like: Week 1: decide the goal of the next activity. Weeks 2-3: preparing documentation, recruiting participants. Week 4: DIY activities start. Support via IRC mailing list. Group sprint on Wed/Thu DIY activities continue. Week 4+1: Evaluation of results. Goal of the next activity During the group sprints there would be secondary DIY tasks for those happy to participate but not fond of the main goal of the week. If one group needs more than one activity per month they can start overflowing the following week, resulting in simultaneous testing bugs activities. Compared to the current situation, this wheel looks powerful and at the same time relatively easy to set up. There will plenty of things to improve and fine tune, but probably none of them will require to stop the wheel. What do you think? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
On Wed, Jan 23, 2013 at 01:53:39PM -0800, Aaron Schulz wrote: I'd strongly suggest considering this kind of approach. Ditto. Among other benefits already mentioned, having a predetermined set of sizes would help greatly in the architecture and capacity planning of media storage, as well as in various maintenance tasks that we occasionally need to do (like replicating thumbnails across datacenters). Regards, Faidon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Announcing the Individual Engagement Grants program
On 01/16/2013 09:48 AM, Quim Gil wrote: Hi, next week I will have a casual chat with Siko about the new Wikimedia Individual Engagement Grants and how MediaWiki contributors could theoretically benefit from them. I just had that chat. Very interesting! Individual Engagement Grants also apply to software development and technical activities https://meta.wikimedia.org/wiki/Grants:IEG Proposals accepted: 15 Jan ‑ 15 Feb The next round will be 6 months later. Individual or team of up to 4 individuals. Scoped to 6 months, with potential to renew for 6 more if need is shown. Maximum request USD 30,000. No minimum. Having an idea and willing to get community feedback before / while converting it in a full fledged proposal? Submit it at https://meta.wikimedia.org/wiki/Grants:IdeaLab Original Message Subject: [Wikimedia-l] [Wikimedia Announcements] Announcing the Individual Engagement Grants program Date: Tue, 15 Jan 2013 18:03:42 -0800 From: Siko Bouterse sboute...@wikimedia.org Reply-To: wikimedi...@lists.wikimedia.org To: wikimediaannounc...@lists.wikimedia.org *Hi all, Im pleased to announce the launch of a new grantmaking program at the Wikimedia Foundation: Individual Engagement Grants. These grants will support Wikimedians as individuals or small teams to complete projects that benefit the Wikimedia movement, lead to online impact, and serve the mission, community, and strategic priorities. This new program is intended to complement WMFs other grantmaking programs as well as the grants that chapters and affiliate organizations provide. The first round of proposals will be accepted from now until 15 February 2013. Were also seeking committee members to help select the first round of grantees. Please help spread the word to other lists! To get involved, share your thoughts, submit a proposal, or join the committee: https://meta.wikimedia.org/wiki/Grants:IEG For more information on all of WMFs grantmaking programs: https://meta.wikimedia.org/wiki/Grants:Start Best wishes,* Siko -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Roadmap change summary for today - tomorrow's tech talk cancelled
Highlighted updates from today's roadmap meeting: - Gabriel Wicke will be announcing a RFC + Roadmap for future Parsoid plans on Wikitech-l shortly http://www.mediawiki.org/wiki/Parsoid/RFC:_Longer-term_plan - EQIAD migration completed. You can see the steps taken here: http://wikitech.wikimedia.org/view/Eqiad_Migration_Planning/Steps For detailed updates, please see: https://www.mediawiki.org/w/index.php?title=Roadmapdiff=633650oldid=633148 *Also, please note that tomorrow's tech talk has been cancelled/postponed.* -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
On 01/23/2013 12:56 PM, Bawolff Bawolff wrote: On 2013-01-23 3:38 PM, Jon Robson jdlrob...@gmail.com wrote: Suggested solution: Maybe some kind of voting system might be of use to force some kind of consensus rather than leaving problems unsolved. I'm fed up of receiving emails about the same problem I discussed weeks before that never got solved. It makes my mailbox ill. I mean if the question is really what colour is the bikeshed it would be good for people to propose colours, people to vote on preferred colours and at the end of say a week the majority colour wins and gets implemented (or in cases where there is no majority we discuss the front runners and other possible solutions). What colour should the polling booth be? I don't think the answer is voting. Perhaps there are some sheds that don't need to be painted. -bawolff P.s. if someone built a bikeshed in the wmf office they would be my hero I have put out a call for one: http://groups.freecycle.org/oaklandfreecycle/posts/27285249 If I get one, I will donate it to the wmf office. LW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
On Wed, Jan 23, 2013 at 3:13 PM, Quim Gil q...@wikimedia.org wrote: [snip] But there is another point here, which is how narrowed / inclusive are we with the MediaWiki word. You can see it as the name of a CMS. You can see it as a name of a wider community. Looking at the content at mediawiki.org it is obvious that such community does a lot more things than developing a CMS. Why not calling all those things under the MediaWiki umbrella, and refer to the CMS as MediaWiki Core? I don't really like that idea. It may be because I'm just cranky and dislike change ;) but MediaWiki and the rest of Wikimedia's technical stuff are fairly orthogonal. I can work on MediaWiki without caring about Wikipedia and friends. I could also work on non-Wikimedia technical infrastructure without caring about MediaWiki. (However, non-MediaWiki Wikimedia tech stuff needs a more concise name (or names). There's a lot of things in this category including wiki-templates, local gadgets, puppet/ops related stuff, some of the mobile stuff, and there is no good name to describe it.) We use names to describe things. If the names become too broad they could lose their usefulness. I would also be concerned that by making MediaWiki (the CMS) subordinate to general wikimedia technical activities by renaming MediaWiki to MediaWiki-core [and having mediawiki=wikimedia-technical-thingies] it could alienate some contributors who are primarily interested in MediaWiki and not Wikimedia. On the other hand that could quite possibly be an imagined problem. As for actual hackathon naming (whatever happened to hackaton, I thought that was a cute name) . I don't think it really matters. Call it MediaWiki if its primarily focused on MediaWiki, call it Wikimedia if its more focused on Wikimedia things. Call it Wikipedia if you really must [As someone who originally came to Wikimedia land via a non-Wikipedia project, calling Wikimedia things Wikipedia makes me go grrr, but I recognize that Wikipedia is a more recognizable brand]. To be honest making naming requirements sounds like a bikeshed discussion. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC: Parsoid roadmap
Fellow MediaWiki hackers! After the pretty successful December release and some more clean-up work following up on that we are now considering the next steps for Parsoid. To this end, we have put together a rough roadmap for the Parsoid project at https://www.mediawiki.org/wiki/Parsoid/Roadmap The main areas we plan to work on in the next months are: Performance improvements: Loading a large wiki page through Parsoid into VisualEditor can currently take over 30 seconds. We want to make this instantaneous by generating and storing the HTML after each edit. This requires a throughput that can keep up with the edit rates on major wikipedias (~10 Hz on enwiki). Features and refinement: Localization support will enable the use of Parsoid on non-English wikipedias. VisualEditor needs editing support for more content elements including template parameters and extension tags. As usual, we will also continue to refine Parsoid's compatibility in round-trip testing and parserTests. Apart from these main tasks closely connected to supporting the VisualEditor, we also need to look at the longer-term Parsoid and MediaWiki strategy. Better support for visual editing and smarter caching in MediaWiki's templating facilities is one area we plan to look at. We also would like to make it easy to use the VisualEditor on small mediawiki installations by removing the need to run a separate Parsoid service. A general theme is pushing some of Parsoid's innovations back into MediaWiki core. The clean and information-rich HTML-based content model in particular opens up several attractive options which are discussed in detail in the roadmap. Please review the roadmap and let us know what you think! Gabriel and the Parsoid team -- Gabriel Wicke Senior Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming our developer events
On 01/23/2013 03:07 PM, bawolff wrote: To be honest making naming requirements sounds like a bikeshed discussion. I'm sorry it has been perceived by some as such. I started the discussion after the real need this morning of suggesting a name to a local promoter willing to organize an event. End of discussion at wikitech-l. If anybody is interested please continue at https://www.mediawiki.org/wiki/Talk:Groups/Promotion#Naming_our_developer_events_23068 The Promotion group is actually the perfect context for discussions about names, logos, events and such. If you are interested in these topics please watch https://www.mediawiki.org/wiki/Groups/Promotion and consider joining the group. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
As the linked thread mentioned, MediaWiki is used on many deployments outside of Wikimedia. For example, I'm running three instances on a server with 10 GB of disk space. Therefore, this should be an option in LocalSettings.php rather than a global change; that way, the installations which are CPU-constrained rather than disk-constrained can use other solutions, from user education to Squid. On 24/01/13 04:15, Jon Robson wrote: I felt the last conversation stalled due to a lack of data and lots of speculation. It would be great if someone in the analytics team could give an idea of the most commonly requested thumbnails and we could use this as the basis for a new conversation. I'd suggest that once we have such a list we standardise on several sizes and deprecate the others - returning the closest size match for those and leaving it to css/width and height attributes to perform the scaling wanted. On Wed, Jan 23, 2013 at 8:25 AM, Petr Kadlec petr.kad...@gmail.com wrote: On 23 January 2013 13:24, Georgiy Tugai georgiy.tu...@gmail.com wrote: However, this is also an avenue for denial of service - someone could create many links to different images with non-standard sizes, intentionally or unintentionally, and therefore overload computational (temporarily) and storage resources on the server. Note that this has been debated at least a few times in the past. See e.g. the thread at http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/63701/ -- [[cs:User:Mormegil | Petr Kadlec]] ___ 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] Limiting storage/generation of thumbnails without loss of functionality
On 01/23/2013 10:07 PM, Georgiy Tugai wrote: As the linked thread mentioned, MediaWiki is used on many deployments outside of Wikimedia. For example, I'm running three instances on a server with 10 GB of disk space. Therefore, this should be an option in LocalSettings.php rather than a global change; that way, the installations which are CPU-constrained rather than disk-constrained can use other solutions, from user education to Squid. Yeah, I think it should probably an option (we could debate the default later). Besides the obvious bandwidth issue, some browsers may do worse scaling then MediaWiki's library (imagemagick I believe). Of course, others might be better. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Hackathon 2013 brainstorming
Greetings, Wikimania is six months away - and in terms of planning - that means it is right around the corner. As such, folks involved with programme and Hackathon organizing are very interested in any ideas that WM developers may have for this year's Hackathon. Please contribute them on-wiki - https://wikimania2013.wikimedia.org/wiki/Hackathon/Brainstorming Or if that is just too much wiki for today - feel free to email me and I'll make sure it gets posted. :) Thank you! -greg aka varnent Wikimania 2013 Programme Committee / geek helping with Hackathon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
On 23/01/13 20:38, Jon Robson wrote: Suggested solution: Maybe some kind of voting system might be of use to force some kind of consensus rather than leaving problems unsolved. I'm fed up of receiving emails about the same problem I discussed weeks before that never got solved. It makes my mailbox ill. I mean if the question is really what colour is the bikeshed it would be good for people to propose colours, people to vote on preferred colours and at the end of say a week the majority colour wins and gets implemented (or in cases where there is no majority we discuss the front runners and other possible solutions). Excuse me, but your proposed solution is wholly inadequate. For example, a few people might prefer a green bikeshed, more people might prefer blue, yet a small majority might prefer awful grey. The greens would of course prefer blue to grey, yet this would not be reflected in the voting outcome. Obviously, if this is ever to be implemented, we need a better way of counting the votes, such as instant-runoff voting. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
