Re: [Wikitech-l] How users without programming skills can help
On Mon, Feb 14, 2011 at 2:46 AM, Diederik van Liere wrote: > So maybe we can paste these 5 steps (or something similar) in the initial > form used to file a bugreport. > > This would increase the quality of bugreports and make it easier for bug > triaging. > Increase the quality perhaps, but also increase the the barrier of reporting bugs, and that is something that is not very good imho. I don't think we have a systematic problem with bad bug reports. The systematic problem is the lack of replies from developers. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patch catch-up: bug 23817 fixes committed
On Mon, Feb 14, 2011 at 12:15 AM, Brion Vibber wrote: > To start out with catching up on patch review, I took a look over and > applied the patches on bug 23817, fixing wfObjectToArray() and FormatJson > for a case that broke certain parts of ForeignAPIRepo when PHP's native JSON > module wasn't present: > > https://bugzilla.wikimedia.org/show_bug.cgi?id=23817 > > The patches were posted by Tim Yates shortly after his bug report in June > 2010; the same bug was re-filed in December as bug 26250, and only > reconnected later. Thanks for the fix, Tim! > > -- brion > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > Yay, good work Brion! Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site
2011/2/13 Ville Stadista : > Currently, if you login on secure you are not logged-in on the > unencrypted site, even if I allow setting third party cookies in the > browser settings. I assume the login session is common to both > unencrypted and encrypted, so would it be possible to transfer the > session from secure.wikimedia.org? This way users could login securely > but choose to use the unencrypted site for the normal tasks. > This is not a bug, it's a feature. If you were automatically logged in on the insecure sites when logging in on the secure site, someone could just trick you to visit wikipedia.org (e.g. by including an image from wikipedia.org on their web page, or through various other means) and your browser will happily send your session cookies to wikipedia.org unencrypted. If that someone happens to also be on the same public wifi and has Firesheep running, they can now hijack your login session. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review going forward
2011/2/13 Mark A. Hershberger : > Right. And while I think your suggestion of assigning 7 developers a > day to do reviews could work, what if we divide the code into different > areas? From looking at the sub-directories under includes/ I would > suggest a different person assigned to API, Parser, Uploads, DB, > Installer, ResourceLoader, Templates, Specials, and probably a couple > assigned to “Everything Else”. > We should definitely do this, and de facto we do this already. This is what I meant by reassigning as appropriate. However, I think it's a good idea to balance "everything else" over all reviewers, even the specialized ones. > The advantage to this, instead of having everyone manage certain days is > that it becomes a smaller, semi-daily activity instead of a larger, > once-a-week activity. My hope is that this would be more likely to get > done on a regular basis. > I was thinking that tying things to certain days would enforce regularity more naturally than per-directory review would. > Side note: I'd like to encourage code reviewers to see this as an > opportunity to work with less experienced developers. We've burdened > some of our most knowledgeable and productive developers with code > review. At least some of this work could be shifted to less experienced > developers. More on that in a bit. > Yes, I wrote the CodeReview sign-off feature with this in mind. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Switch mediawikiwiki to 1.17wmf1
2011/2/13 MZMcBride : > As I recall, it wasn't part of the first set of guinea pigs in case > something went horribly wrong and broke the site. Because mediawiki.org has > the code review tools, having mediawiki.org down when people are trying to > fix deployment problems would itself be a major problem. (It's turtles all > the way down.) > This is exactly why I said we should not use mw.org as one of our initial guinea pigs, yes. However, since 1.17 doesn't seem to have a catastrophic impact on the other dozen or so wikis it's running on, including meta, I think we can go ahead and switch it over now. If CodeReview breaks, we can just switch it back. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making code review happen in 1.18
2011/2/13 Bryan Tong Minh : > I agree... a bit. We should branch 1.18wmf1 immediately from trunk > once things have calmed down a bit. However, this 1.18wmf1 does not > necessarily need to be the base for 1.18. We can branch 1.18wmf2 from > trunk again and so on, until the time that we want to release 1.18 > when we make a final 1.18wmfN branch and 1.18 branch. > +1 If we want to move to continuous integration (and I think the consensus is we do, considering the mess we've made for ourselves by deploying 9 months worth of commits and not knowing which of the ~15,000 new revisions killed the cluster the other day), our first step should be to get closer to continuous integration, i.e. bring deployment closer to trunk. By the time we deploy 1.17, trunk will already be more than two months ahead. Of course this is because we needed time to stabilize 1.17, which in turn was caused by the amount of new code in it. Stabilizing and deploying 1.18wmf1 should take considerably less time and allow us to get much closer to a continuous integration model. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
I am not following this line of reasoning: how can adding guidance / instructions on how to write a good bug report turn people away? In a previous life, I have studied the factors that shorten the time required to fix a big. Bugreports that contain steps to reproduce are a significant predictor to shorten the time to fix a bug. You can find the paper here: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1507233 A systematic lack of replies is also an issue but this solution was not aimed at fixing that problem. On Mon, Feb 14, 2011 at 4:39 AM, Bryan Tong Minh wrote: > On Mon, Feb 14, 2011 at 2:46 AM, Diederik van Liere > wrote: > > So maybe we can paste these 5 steps (or something similar) in the initial > > form used to file a bugreport. > > > > This would increase the quality of bugreports and make it easier for bug > > triaging. > > > Increase the quality perhaps, but also increase the the barrier of > reporting bugs, and that is something that is not very good imho. > I don't think we have a systematic problem with bad bug reports. The > systematic problem is the lack of replies from developers. > > > Bryan > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- http://about.me/diederik";>Check out my about.me profile! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Migrating to GIT (extensions)
If I am not mistaken then mercurial has better support for highly modularized open source software projects. You can use a mercurial subrepository (which is very similar to svn external and git submodule). According to their manual: "Subrepositories is a feature that allows you to treat a collection of repositories as a group. This will allow you to clone, commit to, push, and pull projects and their associated libraries as a group." see: http://mercurial.selenic.com/wiki/Subrepository http://mercurial.selenic.com/wiki/NestedRepositories just my 2 cents. On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland wrote: > > Op 14-02-11 05:01 schreef Daniel Friesen : > > >Ohh... if the translatewiki guys are looking for a dummy for > >streamlining support for extensions based in git in preparation for a > >git migration if we do so, I'd be happy to offer monaco-port up as a > >existing extension (well, skin) using git that could be used as a test > >for streamlining git support. ;) having monaco-port get proper i18n > >while it's still not up to a level I believe I want to commit it into > >svn yet wouldn't be a bad thing. > > With regards to i18n support it is not clear to me how translatewiki staff > would deal with 100+1 commits to different repo's every day if core and > extensions would each be in individual repos. Can you please explain how > Raymond would be working with Windows and Git in the proposed structure > updating L10n for 100 extensions and MediaWiki core? How would > translatewiki.net easily manage MediaWiki updates (diff review/commits)? > > I'm not particularly looking forward to having to jump through a huge > series of hoops just to keep checkouts for single extensions small. If > that is the real issue, extension distribution should get another look as > this might indicate that ExtensionDistributor does not work as expected. I > have currently checked out all of trunk, and for translatewiki.net we have > a selective checkout of i18n files for extensions and we have a checkout > for core and the installed extensions. The fragmentation and > disorganisation/disharmony that will exist after creating 450 GIT repos > instead of one Subversion repo as we currently have is also something I am > not looking forward to. > > Source code management is now centralised, and correct me if I'm wrong, > but we encourage developers to request commit access to improve visibility > of their work and grow the community. "Going distributed" in the proposed > way, would hamper that, if I'm correct. I think the relative lower > popularity of extensions that are maintained outside of svn.wikimedia.org > are proof of this. I am not in favour of using GIT in the proposed way. I > think core and extensions should remain in the same repo. Checkout are for > developers, and developers should get just all of it. > > Siebrand > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- http://about.me/diederik";>Check out my about.me profile! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
2011/2/14 Diederik van Liere : > I am not following this line of reasoning: how can adding guidance / > instructions on how to write a good bug report turn people away? It's very simple, really: a form with a lot of fields may turn people away. I know that it turns me away. How many people are like me in this regard? That is someone that should be studied. I still do report bugs in Firefox, despite the many field in the form, but i can easily imagine people who won't. > In a previous life, I have studied the factors that shorten the time > required to fix a big. Bugreports that contain steps to reproduce are a > significant predictor to shorten > the time to fix a bug. You can find the paper here: > http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1507233 That makes perfect sense, but that's the developer side side of the question. I'm talking about the user side. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
Maybe i am not expressing myself clear, i am not talking about adding checkboxes, radiobuttons or pulldown menus, I am saying that we could add the following text to the textarea field which contains the actual bugreport: "Please describe the steps to take to reproduce the problem:" "What is the expected result:" "What is the actual result:" "If you know which version you are using or you have other information that you think might be helpful please add it as well. You can also describe the problem in your own words and not sticking to the abovementioned questions." So, again I am not saying we should add fields, we could add this text as the default text in the textarea so people have a bit more guidance when writing a bugreport. No hard checks, nothing is mandatory. On Mon, Feb 14, 2011 at 10:22 AM, Amir E. Aharoni wrote: > 2011/2/14 Diederik van Liere : >> I am not following this line of reasoning: how can adding guidance / >> instructions on how to write a good bug report turn people away? > > It's very simple, really: a form with a lot of fields may turn people > away. I know that it turns me away. How many people are like me in > this regard? That is someone that should be studied. > > I still do report bugs in Firefox, despite the many field in the form, > but i can easily imagine people who won't. > >> In a previous life, I have studied the factors that shorten the time >> required to fix a big. Bugreports that contain steps to reproduce are a >> significant predictor to shorten >> the time to fix a bug. You can find the paper here: >> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1507233 > > That makes perfect sense, but that's the developer side side of the > question. I'm talking about the user side. > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- http://about.me/diederik";>Check out my about.me profile! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On 14 February 2011 04:16, Daniel Friesen wrote: > Actually our "users" could be anyone who reads Wikipedia and notices > there's something wrong with what MediaWiki is doing or thinks there is > something about the ui we need to fix. A few of these come into OTRS, specifically the "technical issues" subqueue of info-en. Most aren't bug reports, a few would count as such. Getting technical information from nontechnical users is always a tricky one ... does anyone here keep an eye on that subqueue? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
* Daniel Friesen [Sun, 13 Feb 2011 20:16:53 -0800]: > Actually our "users" could be anyone who reads Wikipedia and notices > there's something wrong with what MediaWiki is doing or thinks there is > something about the ui we need to fix. > > They don't even have to be as advanced as a Firefox user... they could > be a random "human" who doesn't even know they can install a browser > other than Internet Explorer on their computer. > > If someone is already saying it's harder to report a bug to Mozilla > about something they usually install themselves, I don't think we want > reporting to be as hard when we have "users" who don't even know it's > something they can install. > If I understood you correctly (I am not native English speaker), you propose to have built-in bug submission feature in MediaWiki core, so anyone can submit an issue with one button click. Great idea, imho. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On Sun, Feb 13, 2011 at 5:28 PM, MZMcBride wrote: > Mark A. Hershberger wrote: >> Perhaps we could recruit some people from the he.wikipedia.org community > to >> take problems reported (via the localized interface?) and reproduce > them or >> act as a "translator" between developers and bug reporters? > > There is already some infrastructure for this kind of idea: > https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors > > I didn't know about this mailing list until a few days ago, but it's a start > in building the bridge between MediaWiki development and (power-)users. > > MZMcBride Fascinating! I didn't know this existed either. To answer Mark's question, I'm interested in facilitating more user participation in bug-collecting. Using Bugzilla confuses the heck out of me, but mostly because I don't do it very often! There are many good ideas in this list. I have one small idea re: bugzilla -- is it possible to make browsing bugs more transparent (like a link on the sidebar)? I only just discovered that it's possible to look at bugs by category, component or keyword rather than search, and for the hapless newbie who is nonetheless sometimes interested in looking (at) bugs to see what's going on (like me) it would help. First rule of taxonomies: everyone describes stuff differently, so browse is useful :) -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers gmail.com * ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making code review happen in 1.18
- Original Message - > From: "Jeroen De Dauw" > > +1 to migrate to a DVCS > > Unless I'm mistaken no one has actually suggested doing that. 0 + 1 = 1, right? :-) Cheers, -- jra ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
Wow, it's difficult to unwind a middle-posted message. I think that having a wizard to make reporting bugs easier is a great idea, and will likely increase the number of problem reports you have to work with... as long as you don't get it in *my* when when I'm trying to report a bug, thank-you-very-much. :-) Making an easy interface available is wonderful, as long as you don't drive power users up the wall with it, an opinion of mine which I'm sure won't be a surprise to anyone who's watched me post here on wikitext and parsers/editors. :-) Cheers, -- jra - Original Message - > From: "Diederik van Liere" > To: "Wikimedia developers" > Sent: Sunday, February 13, 2011 10:53:48 PM > Subject: Re: [Wikitech-l] How users without programming skills can help > Dear James, Amir and fellow wikimedia devs, > > I understand your concern and I am not suggesting that we should force > a > user to enter all Bugzilla fields but add those 5 questions as a > guideline > in the free-text form. Reporters can use it when they feel uncertain > what > information we are looking for but they are not forced to stick to any > format in particular. > > Additionally, I think that Mediawiki users are as technological > advanced as > Firefox users so I don't think this will scare somebody away. If we > really > want to make it easier for people to file a bug then we should add a > simple > wizard to guide them through the process. In particular choosing the > right > product and component can be quite confusing / intimidating for > somebody new > to Medawiki. > > On Sun, Feb 13, 2011 at 9:43 PM, James Alexander > wrote: > > > On 2/13/2011 8:46 PM, Diederik van Liere wrote: > > > I think we can draw some inspiration from Mozilla's use of > > > Bugzilla and > > > particular the format they are encourage users when submitting a > > bugreport: > > > > > > 1) Steps to reproduce > > > 2) Expected result > > > 3) Actual result > > > 4) Reproducible (by bugreporter): always / sometimes > > > 5) Version information, extensions installed, database used (this > > > information is dependent on the skill level of the bugreporter and > > > maybe > > we > > > can add make this information easily retrievable if it's current > > > not easy > > to > > > determine. > > > > > > So maybe we can paste these 5 steps (or something similar) in the > > > initial > > > form used to file a bugreport. > > > > > > This would increase the quality of bugreports and make it easier > > > for bug > > > triaging. > > > > I can totally understand the idea behind this but I think Amir > > brings up > > the concern about this best: > > > > On 2/13/2011 5:56 PM, Amir E. Aharoni wrote: > > > bugzilla.wikimedia.org is the tracker where i report more bugs > > > than > > > elsewhere. The second is bugzilla.mozilla.org . It's not because > > > Firefox has less bugs (quite the contrary!) but because Mozilla's > > > tracker requires me to fill more fields, such as steps for > > > reproduction. This may encourage detailed reporting that helps > > > developers solve the bugs, but it may also discourage people from > > > reporting them in the first place. > > > ___ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > Gathering all that information on a bug report form could quite > > clearly > > make it easier to reproduce bugs and may make resolving them easier > > but > > I worry that the harder and/or more complicated we make the > > reporting > > the more likely we are to scare someone away from taking the time to > > file the bug (which we want). I'm not totally sure where the best > > balance there is. > > > > -- > > James Alexander > > Associate Community Officer > > Wikimedia Foundation > > jalexan...@wikimedia.org > > +1-415-839-6885 x6716 > > > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > -- > http://about.me/diederik";>Check out my about.me profile! > ___ > 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] Switch mediawikiwiki to 1.17wmf1
On Sun, Feb 13, 2011 at 5:21 PM, Brion Vibber wrote: > On Sun, Feb 13, 2011 at 2:08 PM, Chad wrote: > >> On Sun, Feb 13, 2011 at 4:32 PM, Krinkle wrote: >> > Is there any issues with switching to 1.17wmf1 before the rest goes >> > (say tonight or Monday) ? Currently >> > I'm writing some documentation but the 'new' versions of things don't >> > actually work on mw.org so it's >> > hard demonstrating it, since it won't work on mediawiki.org >> > >> >> I'm +1 on this, but other people should weigh in first, I think. >> > > I, for one, would welcome our new upgraded overlords! > Your wish is my (well...Roan's) command! New code review features are live :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review going forward
Roan Kattouw writes: > We should definitely do this, and de facto we do this already. This is > what I meant by reassigning as appropriate. However, I think it's a > good idea to balance "everything else" over all reviewers, even the > specialized ones. Sure. And specialized reviewers should not be seen as the *only* people who can review code in a particular area. We need cross-pollination and restricting code review access to only specialists does not help this. > I was thinking that tying things to certain days would enforce > regularity more naturally than per-directory review would. I'm sure different people have different ways of working and it won't be till we've field-tested this stuff that we'll really know what is best. The focus now should be on getting regular reviews — keeping the 1.18 branch in close sync with trunk — not on pushing this or that way of doing things. >> Side note: I'd like to encourage code reviewers to see this as an >> opportunity to work with less experienced developers. > > Yes, I wrote the CodeReview sign-off feature with this in mind. Excellent, I haven't had a chance to look at sign-off yet, so this is good news. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
2011/2/12 Guillaume Paumier : > Trevor Parscal and Roan Kattouw, the main developers of ResourceLoader, > will be available on IRC [2] on Monday, February 14th, at 18:00 (UTC) > [3], to answer questions and help fix issues related to ResourceLoader. > Reminder: this is half an hour from now in #wikimedia-office. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
- Original Message - > From: "Diederik van Liere" > "If you know which version you are using or you have other information > that you think might be helpful please add it as well. > You can also describe the problem in your own words and not sticking > to the abovementioned questions." I do want to grab one misconception by the horns here, though it is not as much applicable to Wikipedia proper as it is to Mediawiki, and so may not apply to what Diederik had in his head: If you don't know what version you're using, the bug report will be next to useless, particularly if it's fire and forget. If anyone on this thread hasn't already read Simon 'putty' Tatham's absolutely *excellent* guide to filing bug reports, you probably should. Cheers, -- jra ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On 14 February 2011 17:40, Jay Ashworth wrote: > If you don't know what version you're using, the bug report will be next > to useless, particularly if it's fire and forget. Any bug system has to capture everything possible, obviously. > If anyone on this thread hasn't already read Simon 'putty' Tatham's > absolutely *excellent* guide to filing bug reports, you probably should. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
Diederik van Liere writes: > I am not following this line of reasoning: how can adding guidance / > instructions on how to write a good bug report turn people away? I don't think it would … as long as it is simply guidance and not a required field. If we pre-fill the textarea, for example, with suggestions for the sort of information to provide, then this would help. People do ask me on IRC: “What sort of information should I put?” That is the second most common response I've heard, next to “What do I select for ‘Component'? Do I have to put anything in ‘Assign To'?” I've a feeling that this is the feedback you're getting: a major part of the problem is the overwhelming amount of information people are asked for when they just want to say “When I do X, Y happens. And it shouldn't.” An UploadWizard-style guide for people to report bugs might be helpful but the first step should be to reduce the amount of information that users are asked for. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making code review happen in 1.18
Roan Kattouw writes: > 2011/2/13 Bryan Tong Minh : >> I agree... a bit. We should branch 1.18wmf1 immediately from trunk >> once things have calmed down a bit. However, this 1.18wmf1 does not >> necessarily need to be the base for 1.18. We can branch 1.18wmf2 from >> trunk again and so on, until the time that we want to release 1.18 >> when we make a final 1.18wmfN branch and 1.18 branch. [ SNIP ] > Stabilizing and deploying 1.18wmf1 should take considerably less time > and allow us to get much closer to a continuous integration model. It sounds like you guys are balking at this idea. I'm not familiar with how the wmfN branches have worked, so some input would help. If we have a 1.18 branch that is, as Brion has noted (and supported), a day or two behind trunk at most, is there a reason that the we couldn't branch wmfN from the rolling 1.18 branch? Or even just tag it when we wanted to mark a WMF deployment? Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Migrating to GIT (extensions)
Siebrand Mazeland writes: > With regards to i18n support it is not clear to me how translatewiki staff > would deal with 100+1 commits to different repo's every day if core and > extensions would each be in individual repos. This is one reason I avoided suggesting that we switch to a DVCS for 1.18: The change is too big and dramatic and would impede too many people's workflows without offering an immediate improvement. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Migrating to GIT (extensions)
On Sun, Feb 13, 2011 at 11:18 PM, Siebrand Mazeland wrote: > With regards to i18n support it is not clear to me how translatewiki staff > would deal with 100+1 commits to different repo's every day if core and > extensions would each be in individual repos. Can you please explain how > Raymond would be working with Windows and Git in the proposed structure > updating L10n for 100 extensions and MediaWiki core? How would > translatewiki.net easily manage MediaWiki updates (diff review/commits)? I'm also an advocate for each extension getting its own git repository, but I'm not sure how this would work, to be honest. It is definitely something we'll need to consider. We appreciate the work that you all do, so I'd hate to make life harder for you. If we go this route, we'll need to make sure we figure out a mitigation strategy here. Thankfully, I believe there is one (more below) > Source code management is now centralised, and correct me if I'm wrong, > but we encourage developers to request commit access to improve visibility > of their work and grow the community. "Going distributed" in the proposed > way, would hamper that, if I'm correct. I think the relative lower > popularity of extensions that are maintained outside of svn.wikimedia.org > are proof of this. I am not in favour of using GIT in the proposed way. I > think core and extensions should remain in the same repo. Checkout are for > developers, and developers should get just all of it. DVCS systems like Git really don't operate well on repositories as large as the full MediaWiki repository. Furthermore, most developers only work with core + a few extensions, so I don't think it's fair to force everyone to check out the full mess. Riffing on Diederik's suggestion, Git also has the concept of submodules: http://book.git-scm.com/5_submodules.html I'm betting we'll be able to use submodules to make life better for translatewiki developers. Rob (p.s. Diederik: I think Git submodules actually predate Mercurial submodules, if memory serves me correctly) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making code review happen in 1.18
2011/2/14 Mark A. Hershberger : > If we have a 1.18 branch that is, as Brion has noted (and supported), a > day or two behind trunk at most, is there a reason that the we couldn't > branch wmfN from the rolling 1.18 branch? Or even just tag it when we > wanted to mark a WMF deployment? > That works for me too. wmfN branches can't be tagged from release branches, they have a different structure so you need to run a script that branches off the various parts, but otherwise this sounds good. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
phoebe ayers writes: > Fascinating! I didn't know this existed either. To answer Mark's > question, I'm interested in facilitating more user participation in > bug-collecting. Using Bugzilla confuses the heck out of me, but mostly > because I don't do it very often! Bugzilla is a huge impediment to problem reporting for lay people. Even technically trained ones, like myself, look at the UI and groan. I want to do as much as possible to make problem reporting easier while still retaining some quality-control on the bug reports themselves. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On Mon, Feb 14, 2011 at 1:48 PM, Mark A. Hershberger wrote: > Bugzilla is a huge impediment to problem reporting for lay people. Even > technically trained ones, like myself, look at the UI and groan. I want > to do as much as possible to make problem reporting easier while still > retaining some quality-control on the bug reports themselves. > > Mark. > Part of this is because default configuration for Bugzilla *sucks* The workflow doesn't have to be so awful, and the fields don't have to be so scary. We've just never taken the time to tune it properly to make it nicer & easier to use. I'm not saying it's the best tool in the world (actually all bug trackers suck, I've never used one I really liked), but we're certainly not using it to its full potential. With the impending Bugzilla 4 release, I would like to take some time in setting up the test instance to perhaps play with some of these options to see if we can tweak it into being more useful to everyone. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Migrating to GIT (extensions)
On Feb 14, 2011, at 9:42 AM, Mark A. Hershberger wrote: > This is one reason I avoided suggesting that we switch to a DVCS for > 1.18: The change is too big and dramatic and would impede too many > people's workflows without offering an immediate improvement. > > Mark. I'm not sure how much worse it could really get? The workflow for review and merging is pretty bad as it is right now. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Migrating to GIT (extensions)
On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland wrote: > With regards to i18n support it is not clear to me how translatewiki staff > would deal with 100+1 commits to different repo's every day if core and > extensions would each be in individual repos. Can you please explain how > Raymond would be working with Windows and Git in the proposed structure > updating L10n for 100 extensions and MediaWiki core? How would > translatewiki.net easily manage MediaWiki updates (diff review/commits)? What's the problem with doing a hundred or more commits to different repositories? It be be trivial to script, if that's the problem. > If > that is the real issue, extension distribution should get another look as > this might indicate that ExtensionDistributor does not work as expected. I > have currently checked out all of trunk, and for translatewiki.net we have > a selective checkout of i18n files for extensions and we have a checkout > for core and the installed extensions. The fragmentation and > disorganisation/disharmony that will exist after creating 450 GIT repos > instead of one Subversion repo as we currently have is also something I am > not looking forward to. I don't see that fragmentation in a filesystem sense is relevant here. What disorganisation/disharmony are you talking about? > Source code management is now centralised, and correct me if I'm wrong, > but we encourage developers to request commit access to improve visibility > of their work and grow the community. "Going distributed" in the proposed > way, would hamper that, if I'm correct. I think the relative lower > popularity of extensions that are maintained outside of svn.wikimedia.org > are proof of this. The "decentralized" aspect will be in terms of who gets to change the code, not where it's put. In other words, I'd like to see anyone have equal standing to submit code, not have a separate "commit access" group. The code will still all be hosted by Wikimedia and made available centrally. A DVCS just makes it much easier to do development without having official approval by the upstream project. > I am not in favour of using GIT in the proposed way. I > think core and extensions should remain in the same repo. Checkout are for > developers, and developers should get just all of it. Checkouts are not just for developers. That's one of the pluses of a DVCS -- anyone can check out and maintain local patches in the version control, easily merging them with upstream changes. This is incredibly useful if you're maintaining local, site-specific hacks. I've done it with vBulletin for years (making my own git repository from their tarball releases). It also makes it very easy to submit your hacks for review upstream, if upstream is set up right. On Mon, Feb 14, 2011 at 9:57 AM, Diederik van Liere wrote: > If I am not mistaken then mercurial has better support for highly > modularized open source > software projects. You can use a mercurial subrepository (which is > very similar to svn external and git submodule). According to their > manual: > "Subrepositories is a feature that allows you to treat a collection of > repositories as a group. This will allow you to clone, commit to, > push, and pull projects and their associated libraries as a group." > see: http://mercurial.selenic.com/wiki/Subrepository > http://mercurial.selenic.com/wiki/NestedRepositories I've used git a lot (I use it for everything I want to version) and Mercurial a fair bit (the W3C seems to like it), and I *strongly* prefer git. Major problems I have with Mercurial: 1) It doesn't support lots of useful functionality that's built into git unless you enable various extensions. This includes colored diffs, automatic paging for large output, and rebasing. 2) It makes it much too easy to delete stuff forever. I've had data loss once already due to getting confused by the merge UI during a rebase -- it kept no copies of my work. git always stores everything even after it's no longer accessible through normal means, like after a rebase or reset --hard. It only cleans up untouched stuff during periodic garbage collection. On the other hand, there's basically nothing I've seen in Mercurial where I've said "wow, I wish git had that". So for what my opinion is worth, we should be going for git, not Mercurial, despite the former's quirks and flaws. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
David Gerard wrote: > On 14 February 2011 17:40, Jay Ashworth wrote: > >> If you don't know what version you're using, the bug report will be next >> to useless, particularly if it's fire and forget. > > Any bug system has to capture everything possible, obviously. Including private or semi-private information (such as installed fonts, IP address, user-agent string, referring web page, etc.)? While some information can definitely be helpful to resolving a bug, there are privacy (policy) considerations to make as well. It's bad enough that Bugzilla currently requires using your e-mail address (which ends up getting spammed, for the record). As Mark has hinted at (or even directly said), a bug filing wizard in a MediaWiki extension seems like the way to go here. I suppose we should have a bug about writing that MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Simple Search Simplification
I was working on fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=27332 (resolved in r82155) and started messing with removing most of the gratuitous lines in the search UI. Here's a screenshot of what we could do instead. I have a patch for this that works in all browsers, including IE6. Screenshot: http://i54.tinypic.com/14d109f.png Patch: http://pastebin.com/WjZwpdez - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
phoebe ayers wrote: > There are many good ideas in this list. I have one small idea re: > bugzilla -- is it possible to make browsing bugs more transparent > (like a link on the sidebar)? I only just discovered that it's > possible to look at bugs by category, component or keyword rather than > search, and for the hapless newbie who is nonetheless sometimes > interested in looking (at) bugs to see what's going on (like me) it > would help. First rule of taxonomies: everyone describes stuff > differently, so browse is useful :) I don't know about others, but I personally find the Bugzilla interface to be a complete pain-in-the-ass and just generally awful. Any search of the bugs in the system is often slow and filled with noise. One way to solve this is to bypass the current Bugzilla interface altogether. In the same way that people can create neat and awesome tools using the replicated wiki databases, the Bugzilla database can (and should) be replicated to Toolserver users to allow them to have direct database access. Direct database access makes it infinitely easier to build tools that could, for example, support a better tagging system. I'd like to see all bugs that affect wikipedia, that affect en.wikipedia, that are user interface related, etc. A separate tags system would be awesome, in my view, as the one in Bugzilla currently sucks. Direct database access also would allow for better (and faster) reports that could be output in a web tool or on a wiki (with versioning!). Which bugs have the most comments? Which bugs have no comments? Some of this information is query-able from the Bugzilla interface, but as I said, it's very slow to query and getting the query written takes way more time and energy than it should (if it's possible at all). To this end, I filed a JIRA ticket with the Toolserver ops about getting the Wikimedia Bugzilla database replicated with public views: https://jira.toolserver.org/browse/TS-901 I have no tricks up my sleeve to get this moving along other than occasionally poking people about it, though. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
I don't know about others, but I personally find the Bugzilla interface to > be a complete pain-in-the-ass and just generally awful. Any search of the > bugs in the system is often slow and filled with noise. One thing that bugged me a while: Why does the bz robots.txt deny any bots? I think having it indexed by google & co would'nt exactly make searching harder. Leo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
Chad wrote: > Part of this is because default configuration for Bugzilla *sucks* > The workflow doesn't have to be so awful, and the fields don't > have to be so scary. We've just never taken the time to tune it > properly to make it nicer & easier to use. I'm not saying it's the > best tool in the world (actually all bug trackers suck, I've never > used one I really liked), but we're certainly not using it to its full > potential. > > With the impending Bugzilla 4 release, I would like to take some > time in setting up the test instance to perhaps play with some of > these options to see if we can tweak it into being more useful to > everyone. I don't think there's going to be any magical set of configuration changes to make Bugzilla less horrible, but it's certainly worth a shot. In the meantime, I've filed bug 27421, "Write and implement bug reporting wizard": https://bugzilla.wikimedia.org/show_bug.cgi?id=27421 MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simple Search Simplification
On Mon, Feb 14, 2011 at 7:27 PM, Trevor Parscal wrote: > I was working on fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=27332 > (resolved in r82155) and started messing with removing most of the gratuitous > lines in the search UI. Here's a screenshot of what we could do instead. > I don't like it really :-\ I like having the space around the box. It helps set it out from the rest of the bar. With your changes, it kind of blurs the distinction, at least to me. I'm just one opinion though, and by my own account suck at everything related to making a UI. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On Mon, Feb 14, 2011 at 8:01 PM, MZMcBride wrote: > I don't think there's going to be any magical set of configuration changes > to make Bugzilla less horrible, but it's certainly worth a shot. > Neither do I, Bugzilla is always going to suck. Maybe we can make it suck a little less though ;-) > In the meantime, I've filed bug 27421, "Write and implement bug reporting > wizard": https://bugzilla.wikimedia.org/show_bug.cgi?id=27421 > I mentioned this earlier today in IRC, but I'll mention it again here on- list. Take a look at the "Guided format"[0] for entering bugs. These templates can be customized, and I think we can use that as a starting point for creating nicer bug input forms (think: separate forms for enhancements vs. actual bugs). -Chad [0] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&format=guided ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simple Search Simplification
I agree. I think that the search box needs to be distinct and obvious as a control; this change blends it into the background too much. Since search is one of our most important features, it should stand out and be easier to target visually, not less. On 2/14/11 6:27 PM, Chad wrote: > On Mon, Feb 14, 2011 at 7:27 PM, Trevor Parscal > wrote: >> I was working on fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=27332 >> (resolved in r82155) and started messing with removing most of the >> gratuitous lines in the search UI. Here's a screenshot of what we could do >> instead. >> > > I don't like it really :-\ I like having the space around the box. > It helps set it out from the rest of the bar. With your changes, > it kind of blurs the distinction, at least to me. I'm just one > opinion though, and by my own account suck at everything > related to making a UI. > > -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] How users without programming skills can help
On Mon, Feb 14, 2011 at 4:44 PM, Leo wrote: > One thing that bugged me a while: > Why does the bz robots.txt deny any bots? I think having it indexed by > google & co would'nt exactly make searching harder. > Bugzilla actually ships with a default robots.txt that denies everything, we just never removed it. :) I don't know offhand how friendly Bugzilla is to direct indexing, but did stumble on some sort of extension to generate a sitemap (have not used it, don't know if it works well): http://code.google.com/p/bugzilla-sitemap/ Might also want to double-check if the issue of exposing commenters' raw email addresses to unlogged-in spiders has been resolved. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On Tue, Feb 15, 2011 at 12:35 PM, Chad wrote: > I mentioned this earlier today in IRC, but I'll mention it again here on- > list. Take a look at the "Guided format"[0] for entering bugs. These > templates can be customized, and I think we can use that as a starting > point for creating nicer bug input forms (think: separate forms for > enhancements vs. actual bugs). > > -Chad > > [0] > https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&format=guided > The guided form sucks, I've used it a few times on the Mozilla BZ install, I think most (if not all) people would find the plain "add bug" screen easier to use. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Status of mobile site rewrite
On Feb 11, 2011, at 8:36 AM, MZMcBride wrote: > Hi. > > There are a few open bugs about adding mobile site support to a specific > Wikimedia wiki. For example, bug 27290 is about creating a mobile main page > for fa.m.wikipedia.org.[1] > > What's the status of the mobile site / mobile site rewrite?[2] I'm mostly > curious because I think these open bugs can be made a dependency of the > rewrite bug, but that's only really true if development work has stopped on > the current mobile site implementation. I think I read that work had stopped > in a bug comment at some point (or at least it was intimated), but I'm not > sure. > > Does anyone know what the current status is? Sure, were currently still hunting around for a full time dev as you can see here http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_(Mobile) If there is anyone who's interested in helping on this as a volunteer or as a full time dev then please contact me or Hampton. So far the pool of applicants has been low so it would be great to get more help. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How users without programming skills can help
On Tue, Feb 15, 2011 at 10:44 AM, Leo wrote: > One thing that bugged me a while: > Why does the bz robots.txt deny any bots? I think having it indexed by google > & co would'nt exactly make searching harder. > > Leo Probably because historically you couldn't hide email addresses from anon (non logged in) users, and well not everyone is a fan of having their email harvested by bots that obey the robots file. -Peachey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] categorisation issues in dumps
Thanks for your help, it indeed works. From: wikitech-l-boun...@lists.wikimedia.org [wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Platonides [platoni...@gmail.com] Sent: 09 February 2011 05:32 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] categorisation issues in dumps Anthony Ventresque (Dr) wrote: > Hi, > > I am trying to build an offline version of the wikipedia categorisation tree. > As usual with projects on wikipedia, I've downloaded dumps (actually the > interesting one here is pages-articles.xml). And I found that none of the > dumps has the relation between "Category:1960_works" and "Category:1960" > which is present on the web page. And it is the same for a lot of categories > I tried: many links are missing in the dump, but are present in the web. Any > idea why is that so? > > Thanks for your help, > Anthony Using page.sql.gz and categorylinks.sql.gz would be more efficient for your task. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you. Towards A Sustainable Earth: Print Only When Necessary ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] strange page id numbering
Hi, I've found something strange in some files. The maximum ids for a page are: latest pages-articles.xml: 29189922 page.sql: 28707562 categorylinks.sql: 28705949 (15,684 categories and 135,521 articles are missing) 2011-01-15 pages-articles.xml: 30492297 page.sql: 30480288 categorylinks.sql: 30479519 Any idea why these numbers are different? Thanks for your help, Anthony CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you. Towards A Sustainable Earth: Print Only When Necessary ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
