[Wikitech-l] Criteria for serious alternative
On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis fai...@wikimedia.orgwrote: My understanding of the process was that we would collect a broad set of arguments/ideas/proposals and people would be later assigned to the task of evaluating them and proposing a viable solution and a migration path (or not, and propose that we stay with Gerrit). Hi Faidon, Yes, we're seeking a broad range of proposals. However, proposals is the key word. That means looking the requirements, reading the website and matching against those requirements, and stitching together something that at least looks good on paper. I'm not expecting anyone to set up a prototype, but I am asking that, given how long we've been talking about this, that we narrow down our options a bit to the things that we know are worth looking at rather than (still, a year later) having the have you looked at this? discussion again. As far as people being assigned to the the task of evaluating them, I think you may be overestimating the number of people we have floating around to do this work. People is basically Chad, who is pretty burnt out on working on this, and is exasperated with this process, but without drafting someone outside my group (like you?) :), I don't have many options. Having Chad do this means taking one of our most experienced MediaWiki developers, and having him not work on MediaWiki, but instead, do more evaluation of code review tools. Before doing that to Chad, I'm asking people who believe passionately that we need to move off Gerrit to actually tell us what they'd like to move to in a structured, constructive way. I don't think that's too much to ask. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride z...@mzmcbride.com wrote: Ryan Lane wrote: You've already admitted that you don't use Gerrit, so do you have a really large stake in this? Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most people, I think I would use Gerrit more if it weren't so awful. Just tonight I was trying to get an index of Gerrit contributors (owners, I guess the term is). Something similar to this list from the SVN system: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author. Apparently Gerrit doesn't have a feature to list authors like this. All I wanted to do was find a particular user and look at his contributions. And, as usual, it took twenty minutes instead of ten seconds because Gerrit sucks. So, you found something you'd like added to the software: a user list. Have you entered a bug? The problem you are encountering is that you are used to a piece of software, and the new software doesn't have the exact same feature set. This happens, and will happen with any new tool if we switch, too. There's an open bug for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=35508 Note that the bug mentions a number of ways you can get a user list outside of Gerrit. I think it would be nice to have Gerrit itself have the user list interface. With extension support in Gerrit 2.5, we may be able to implement it ourselves. How does anyone use Gerrit? I use it successfully every single day. I review code, I add changes, I get statistics on repos. It works well for me. Guess what? I find the old code review system to be just as hard to use as Gerrit. Know why? I didn't use the old code review system much. Every release *has* been much better and the releases are often, and that's a great thing. It's not a corporate justification, it's reality. Having a really responsive and active upstream is awesome. You'll have to forgive me, but the only way I can read this is, the car now breaks down two minutes into the journey; it used to break down a minute in! This is a fallacious argument. For most use cases Gerrit works perfectly well. The fixes coming in each release are easing some of the use cases that don't work so well. Maybe as a non-developer Gerrit doesn't do what you want. As a developer it does most of what I want. It doesn't do some things I want, though. I want free-form tagging, for instance, which is on the roadmap for a future release (and Chad has already started adding in code that is required for this feature). I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset. I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles. As mentioned at least twice already in these threads, this is simply not true. It's possible to fix the CSS right now (and if you look at OpenStack's Gerrit, you'd notice they've already done so). We can just give people accounts now, and we eventually allow people to self-register as well. In fact, this is one of my top goals after upgrading openstack and adding a new Labs zone in eqiad. Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 (Creating a Git/Gerrit/Labs account requires human intervention). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how the current account creation process works, I can't help or find anyone to help make it better. I could have sworn there was another bug open for this that documented what needed to get done. I just spent a few minutes updating the bug. It's likely a fairly small OpenStackManager change, and a labsconsole configuration change. As mentioned it's on my list after Labs upgrades. If someone else wants to tackle it first, I'd love that. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Thu, 26 Jul 2012 23:43:51 -0700, Ryan Lane rlan...@gmail.com wrote: On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride z...@mzmcbride.com wrote: Ryan Lane wrote: You've already admitted that you don't use Gerrit, so do you have a really large stake in this? Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most people, I think I would use Gerrit more if it weren't so awful. Just tonight I was trying to get an index of Gerrit contributors (owners, I guess the term is). Something similar to this list from the SVN system: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author. Apparently Gerrit doesn't have a feature to list authors like this. All I wanted to do was find a particular user and look at his contributions. And, as usual, it took twenty minutes instead of ten seconds because Gerrit sucks. So, you found something you'd like added to the software: a user list. Have you entered a bug? The problem you are encountering is that you are used to a piece of software, and the new software doesn't have the exact same feature set. This happens, and will happen with any new tool if we switch, too. There's an open bug for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=35508 Note that the bug mentions a number of ways you can get a user list outside of Gerrit. I think it would be nice to have Gerrit itself have the user list interface. With extension support in Gerrit 2.5, we may be able to implement it ourselves. How does anyone use Gerrit? I use it successfully every single day. I review code, I add changes, I get statistics on repos. It works well for me. Guess what? I find the old code review system to be just as hard to use as Gerrit. Know why? I didn't use the old code review system much. Every release *has* been much better and the releases are often, and that's a great thing. It's not a corporate justification, it's reality. Having a really responsive and active upstream is awesome. You'll have to forgive me, but the only way I can read this is, the car now breaks down two minutes into the journey; it used to break down a minute in! This is a fallacious argument. For most use cases Gerrit works perfectly well. The fixes coming in each release are easing some of the use cases that don't work so well. Maybe as a non-developer Gerrit doesn't do what you want. As a developer it does most of what I want. It doesn't do some things I want, though. I want free-form tagging, for instance, which is on the roadmap for a future release (and Chad has already started adding in code that is required for this feature). I want whatever review system we use to support real review branches; - Review sets are heads with multiple commits, not single commits. - We don't amend commits, we make new ones to the head of the review branch. - -no-ff merge commits are used so that only the final commit code makes it directly into master. Scrap all the other complaints. This pattern of amending commits is by far the worst thing about our current workflow. Development history and minor contributions that never make it into the repo. Committer going to the person who fixes a typo rather than the person who writes the code. Confusion over whether someone has rebased or let unrelated changes leak into their patchset. Huge development effort by multiple people potentially turning into a single commit with a single committer. ... At this point I think the real question we have is this: Can we reasonably get Gerrit to support real review branches? If that answer to that question is no. Or not without very significant development. Then the only option we have is to track down the system that we can get to support that with the most reasonable amount of development effort. I know people complain about Gerrit a lot, but I personally find it much better than our previous toolset. I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles. As mentioned at least twice already in these threads, this is simply not true. It's possible to fix the CSS right now (and if you look at OpenStack's Gerrit, you'd notice they've already done so). We can just give people accounts now, and we eventually allow people to self-register as well. In fact, this is one of my top goals after upgrading openstack and adding a new Labs zone in eqiad. Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 (Creating a Git/Gerrit/Labs account requires human intervention). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how
Re: [Wikitech-l] Criteria for serious alternative
Le 27/07/12 04:04, MZMcBride wrote: snip It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software (you can hack the code!) who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit. You can change the CSS, even the head/footer html: http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/config-headerfooter.html Openstack has a different style: https://review.openstack.org/ Roan did a skin that even ship jQuery: https://gerrit.wikimedia.org/r/#/c/3285/ So that is definitely doable. It is currently blocked because the build-in CSS are loaded AFTER the user CSS which is totally dumb but is definitely an easy fix. A few people on this list have gone so far as to say but the next release is always better! I realize I was being a bit tongue-in-cheek by suggesting earlier that Gerrit's UI was developed by Microsoft, but to have developers now spouting corporate justifications for shitty software? I'm left to wonder what the hell happened. It goes better after each releases and they upstream release often. That is definitely better than a company throwing a bone at the community from time to time or not willing to merge community patches. The UI could probably have used a designer. As for the Microsoft, I remember from the 90's some design guidance for third parties such as how to position buttons, the margin to let around them and so on. I urge you to have a look at the Windows Phone 7 GUI which is definitely nicer, cleaner and easier to use than the Android/iPhone interfaces. http://www.microsoft.com/windowsphone/ I'm lost as to how Gerrit was ever considered an option previously and how it's still an option on the table today, given its apparent inflexibility. I did mention how Android used a homemade tool to do the reviews. It was introduced to me by a friend who is doing Android development for mobile phone companies. At first I was like: what about the existing google code or github? Then he explained me their pre commit workflow and it made me sure we wanted to use that. I think Ryan met the OpenStack folks who are using Gerrit. That probably convinced him it was the right tool for us too. Say what you will about MediaWiki's CodeReview extension, but on its worst day, it never garnered as much resentment as Gerrit. Our CodeReview tool lacked a good set of features such as the inline commenting (which I coded but was reverted when 1.19 came live). It made it very difficult to keep track of the follow up and comment reply. Overall I am not regretting our old tool and will never come back to it. MZ, Do you even have a labs account? Your continuous rants are far from being constructive and makes everyone lose their time. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
Daniel Friesen write: I want whatever review system we use to support real review branches; - Review sets are heads with multiple commits, not single commits. - -no-ff merge commits are used so that only the final commit code makes it directly into master. We have disallowed branch creation and merging for now, that can definitely be opened up. Chad recently opened the sandbox reference and we have a few of them: remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox - We don't amend commits, we make new ones to the head of the review branch. You will be able to do that. I am afraid the end result is not going to look nice history wise with ton of followups to fix previous commits. That will definitely make finding the root cause of bug and its context harder to find out. Think about a commit that introduce a bug for which the commit message is: Ahh typo in 3124a09 fix it It is not going to be helpful :-D Scrap all the other complaints. This pattern of amending commits is by far the worst thing about our current workflow. I firmly disagree with you there. It let someone send some code then enhance it without cluttering everyone else code. That let you work in a collaborative way, finding out what the other person has done patch after patch. We eventually end up with a patchset that only got published (merged) to everyone whenever it is close to perfect. That makes our code history nicer and push the review stress to the submitters (lot of people) instead of toward the reviewers (few people). I do agree though that the system can be confusing and is poorly toolized. git-review is a step to abstract the whole patchset system, but I am sure we can make it a better/easier tool to use. Development history and minor contributions that never make it into the repo. I think we do not care about the history of a change. The typo / comment update / logic errors, I am sure we do not care about. If someone has a change that requires to be split in several changes, that should easier be a branch (see sandbox above) or a chain of changes made interdependants (which is really just a local branch). How would you do that? Well lets say I want to update our documentation to several area. I would first create a local branch: git checkout -b doc -t origin/master do my doc updates, commit as needed I then push that local branch to Gerrit (git push doc:refs/for/master), that craft a change per commit. Whenever one of the commit need to be amended I edit my local branch commits with git rebase --interactive. Once happy I repush the whole branch and Gerrit magically update all the patchsets. The drawback is that editing just a commit out of several one will still trigger a new patchset to all the child commits although there is no code change per see (the parent got changed). That could be detected in Gerrit I guess. We might have Gerrit to automatically rebase children whenever a parent is modified. Gerrit could also use a feature to prevent the chain of commits to be submitted until they have all been reviewed. Once the last change is submitted, that will trigger a git merge --no-ff. We currently have to handle that manually by submitting the first commit last. Committer going to the person who fixes a typo rather than the person who writes the code. The Author field is kept around (unless someone amend it). See as an example https://gerrit.wikimedia.org/r/#/c/5550/, I am the patch author, Saper sent patchset 3 but I am still mentioned as the author. git does not support multiple authors as far as I know, but one could add himself in the commit message by adding a new field such as: Co-authored-by: John Doh john...@example.org Confusion over whether someone has rebased or let unrelated changes leak into their patchset. That is more a matter of educating our developers. Whenever I submit a new patchset, I add a cover message in Gerrit to introduce what that change did even if it is just a rebase. Huge development effort by multiple people potentially turning into a single commit with a single committer. ... As I said previously, huge effort involving multiple persons could be made branch. At this point I think the real question we have is this: Can we reasonably get Gerrit to support real review branches? The answer is most definitely yes. We would need to open up branches creations to everyone. If that answer to that question is no. Or not without very significant development. Then the only option we have is to track down the system that we can get to support that with the most reasonable amount of development effort. I tend to agree on that :-) -- Antoine hashar Musso ___ Wikitech-l mailing list
Re: [Wikitech-l] Criteria for serious alternative
On Fri, 27 Jul 2012 01:10:52 -0700, Antoine Musso hashar+...@free.fr wrote: Daniel Friesen write: I want whatever review system we use to support real review branches; - Review sets are heads with multiple commits, not single commits. - -no-ff merge commits are used so that only the final commit code makes it directly into master. We have disallowed branch creation and merging for now, that can definitely be opened up. Chad recently opened the sandbox reference and we have a few of them: remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox - We don't amend commits, we make new ones to the head of the review branch. You will be able to do that. I am afraid the end result is not going to look nice history wise with ton of followups to fix previous commits. That will definitely make finding the root cause of bug and its context harder to find out. Think about a commit that introduce a bug for which the commit message is: Ahh typo in 3124a09 fix it It is not going to be helpful :-D Scrap all the other complaints. This pattern of amending commits is by far the worst thing about our current workflow. I firmly disagree with you there. It let someone send some code then enhance it without cluttering everyone else code. That let you work in a collaborative way, finding out what the other person has done patch after patch. We eventually end up with a patchset that only got published (merged) to everyone whenever it is close to perfect. That makes our code history nicer and push the review stress to the submitters (lot of people) instead of toward the reviewers (few people). I do agree though that the system can be confusing and is poorly toolized. git-review is a step to abstract the whole patchset system, but I am sure we can make it a better/easier tool to use. Development history and minor contributions that never make it into the repo. I think we do not care about the history of a change. The typo / comment update / logic errors, I am sure we do not care about. If someone has a change that requires to be split in several changes, that should easier be a branch (see sandbox above) or a chain of changes made interdependants (which is really just a local branch). How would you do that? Well lets say I want to update our documentation to several area. I would first create a local branch: git checkout -b doc -t origin/master do my doc updates, commit as needed I then push that local branch to Gerrit (git push doc:refs/for/master), that craft a change per commit. Whenever one of the commit need to be amended I edit my local branch commits with git rebase --interactive. Once happy I repush the whole branch and Gerrit magically update all the patchsets. The drawback is that editing just a commit out of several one will still trigger a new patchset to all the child commits although there is no code change per see (the parent got changed). That could be detected in Gerrit I guess. We might have Gerrit to automatically rebase children whenever a parent is modified. Gerrit could also use a feature to prevent the chain of commits to be submitted until they have all been reviewed. Once the last change is submitted, that will trigger a git merge --no-ff. We currently have to handle that manually by submitting the first commit last. Committer going to the person who fixes a typo rather than the person who writes the code. The Author field is kept around (unless someone amend it). See as an example https://gerrit.wikimedia.org/r/#/c/5550/, I am the patch author, Saper sent patchset 3 but I am still mentioned as the author. git does not support multiple authors as far as I know, but one could add himself in the commit message by adding a new field such as: Co-authored-by: John Doh john...@example.org Confusion over whether someone has rebased or let unrelated changes leak into their patchset. That is more a matter of educating our developers. Whenever I submit a new patchset, I add a cover message in Gerrit to introduce what that change did even if it is just a rebase. Huge development effort by multiple people potentially turning into a single commit with a single committer. ... As I said previously, huge effort involving multiple persons could be made branch. At this point I think the real question we have is this: Can we reasonably get Gerrit to support real review branches? The answer is most definitely yes. We would need to open up branches creations to everyone. If that answer to that question is no. Or not without very significant development. Then the only option we have is to track down the system that we can get to support that with the most reasonable amount of development effort. I tend to agree on that :-) Most of your reply
[Wikitech-l] Responsive web design
Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On 27 July 2012 11:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ http://blog.tommorris.org/post/21073443312/introducing-awfulness-js HTML 3.2 is looking better every day ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? I am currently working a bit on the skin for http://säsongsmat.nu to make it more responsive (I've gone through the head and footer, but still have work to do on the article rendering, e.g. hooking into the MW image rendering). Let me know if you want me to share the code! Best regardsLeo Wallentin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
This is one of the aims of the planned 'Athena' skin: https://www.mediawiki.org/wiki/Athena Pete / the wub On 27 July 2012 11:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ ___ 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] Responsive web design
On 27 July 2012 12:53, Peter Coombe thewub.w...@googlemail.com wrote: This is one of the aims of the planned 'Athena' skin: https://www.mediawiki.org/wiki/Athena Pete / the wub Very interesting. Looks very good already. On 27 July 2012 12:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ Ouch. This website is aligned to the left, and designed for a fixed width of 1024px. *reads content* Yet again, we remember that HTML is liquid. Is supposed to be, wen is made fixed, is because compromises. On 27 July 2012 12:08, David Gerard dger...@gmail.com wrote: On 27 July 2012 11:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ http://blog.tommorris.org/post/21073443312/introducing-awfulness-js HTML 3.2 is looking better every day ... Infinite scrolling is not always evil. If you need to show a PDF document as a list of 200 high resolution JPG files. You can make the page height the resulting height if all the jpg where downloaded. But only download the JPG the user is looking at. If you try the naive approach,and create a html that links with img all the 700KB jpg files, the page will chocke for most users, because will ask for too much bandwidth too quick. And maybe the users only need to look at the first page, to confirm is interesting (maybe are books, and is the wrong book, or in the wrong language ). http://es.scribd.com/doc/6457786/Godel-Escher-Bach-by-Douglas-R-Hofstadter- By making a document become a computer program, we probably lose the ability to garantee it will end rendering before the end of the existence of the universe. But is often a good tradeoff. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 2:36 AM, Rob Lanphier ro...@wikimedia.org wrote: As far as people being assigned to the the task of evaluating them, I think you may be overestimating the number of people we have floating around to do this work. People is basically Chad, who is pretty burnt out on working on this, and is exasperated with this process, but without drafting someone outside my group (like you?) :), I don't have many options. Having Chad do this means taking one of our most experienced MediaWiki developers, and having him not work on MediaWiki, but instead, do more evaluation of code review tools. Before doing that to Chad, I'm asking people who believe passionately that we need to move off Gerrit to actually tell us what they'd like to move to in a structured, constructive way. I don't think that's too much to ask. I'd like to just clarify Rob's comments here, since they're about me :) When Rob says burnt out, I really am tired. This process has been very draining, but necessary. It's very important that we get this right, which is why I've been committed since day 1 to helping absolutely everyone with absolutely everything relating to Git. Got a question? Ask me. Need a new repo? Ask me. But being a one-man-army tires you after awhile and that's where I'm at right now. But like I said, I'm committed to seeing this through and making sure we're in the best possible position going forward. I feel like exasperated has a bit of a negative connotation to it. Better way to describe it would be would very much like for this to find resolution so I can fade back into obscurity and work on cool things again, like Config overhaul which I really really want to see done so much. :) Again, I'm here to support the community on this. Whatever the end result is, I'll be behind it. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 3:46 AM, Antoine Musso hashar+...@free.fr wrote: So that is definitely doable. It is currently blocked because the build-in CSS are loaded AFTER the user CSS which is totally dumb but is definitely an easy fix. It's not quite as easy as I had hoped, unfortunately. However, it can be worked around (slap !important on everything), and I am still very actively researching a fix for it. In fact, I spent the vast majority of this week playing with upstream. Other than researching that bug, a couple of other cool things I worked on were: 1) I reviewed some improvements made by another developer to the plugin interface that will make it into 2.5. 2) I wrote my own plugin (in less than an hour and less than 100 LOC) to solve a silly issue I've hit. 3) I contributed a lot of fixes to the delete-project plugin (which we need, badly), and as a result it's now working and will be coming out along with 2.5. 4) I also spent quite a bit of time diagnosing some of the diff bugs that people have been hitting in Webkit-based browsers. I didn't get a fix, but I did find out a lot and reported all that information upstream. Also, if anyone tells me that upstream is not active enough, I ask you to please look at a commit I made 2 days ago[0]. I know it wasn't earth- shattering, or even really important. What was important, is that it was reviewed and merged in *less than a minute* without any action on my part. All upstream contributions receive quite a bit of feedback, and things get merged into master every single day. I talk with the Gerrit guys constantly, and they've been nothing but supportive and helpful in both my questions and helping to resolve our issues. -Chad [0] https://gerrit-review.googlesource.com/#/c/36980/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
Antoine Musso wrote: MZ, Do you even have a labs account? Your continuous rants are far from being constructive and makes everyone lose their time. Nope. I looked at getting one once or twice, but the process seemed too bureaucratic and I ended up walking away. I imagine I'll make one once self-registration becomes possible. I don't think it's fair to say that my posts have been unconstructive. I've tried to present actual problems (such as the lack of an authors list) that inhibit being able to effectively use Gerrit. I've also documented my experiences with Gerrit's UI, which to me is completely unintuitive (for example, finding the code inspection links beneath tree or gitweb took me weeks). In May, I tried to create a page about Gerrit's problems: https://www.mediawiki.org/wiki/Gerrit/Problems. I don't know Java or Prolog, otherwise I might have offered to help improve Gerrit directly. Instead, all I can do is share my experiences with the tool in a conversation about it and alternatives. You sound frustrated in your post, hashar, but I don't think you're frustrated with me. If I had to use Gerrit every day (in its current form), I'd be frustrated as well. Though in its defense, once you learn where the secret links and menus and buttons are, most of the needed functionality is there. Ryan Lane wrote: So, you found something you'd like added to the software: a user list. Have you entered a bug? The problem you are encountering is that you are used to a piece of software, and the new software doesn't have the exact same feature set. This happens, and will happen with any new tool if we switch, too. There's an open bug for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=35508 Thank you for the bug link. Note that the bug mentions a number of ways you can get a user list outside of Gerrit. I think it would be nice to have Gerrit itself have the user list interface. With extension support in Gerrit 2.5, we may be able to implement it ourselves. It feels a bit like buying a car that has no steering wheel. I didn't really want to overrun our bug tracker with Gerrit bugs, but I can certainly file a few against it. I'm not trying to be an asshole, but I really don't understand how such a basic feature is missing (which is what I meant by how does anyone use Gerrit?). There's a dashboard feature that accepts user IDs to view a particular user's contributions to Gerrit, but without an index (or some other way to match IDs to usernames), I really have no idea how you're supposed to be able to look at a particular user's contributions. I think a lot of people are frustrated by the fact that the types of problems being encountered in Gerrit would typically be trivial to fix (CSS precedence, for example). The fact that they're not runs against a lot of core Wikimedia principles. As mentioned at least twice already in these threads, this is simply not true. It's possible to fix the CSS right now (and if you look at OpenStack's Gerrit, you'd notice they've already done so). I know about OpenStack's CSS customizations. With regard to Wikimedia's Gerrit installation and CSS, I'll believe it when I see it. :-) Yes, self-registration would be fantastic. :-) I commented on this bug last Saturday: https://bugzilla.wikimedia.org/show_bug.cgi?id=37628 (Creating a Git/Gerrit/Labs account requires human intervention). I realize that you and the other ops folks are busy, but if someone could at least explain the current process, it would give volunteer developers a fighting chance of helping out. Not having the faintest idea how the current account creation process works, I can't help or find anyone to help make it better. I could have sworn there was another bug open for this that documented what needed to get done. I just spent a few minutes updating the bug. It's likely a fairly small OpenStackManager change, and a labsconsole configuration change. As mentioned it's on my list after Labs upgrades. If someone else wants to tackle it first, I'd love that. Great, thank you for updating the bug. And thank you both for your thoughtful replies. I appreciate them. :-) For what it's worth, I think Ryan makes a compelling case for sticking with Gerrit (and I'm still not convinced that another switch would do more good than harm). I'm still deeply worried about the ability to use and improve Gerrit. It would be horribly painful to see all of the work switching from SVN to Git (a large portion of which was intended to allow easy code contributions) go to waste because this particular Git front-end has scared everyone away. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
The Wikipedia mobile site is being made mobile first using responsive design techniques. The plan is for it to eventually mature into a responsive Athena skin that can also be used on desktop. On Jul 27, 2012 4:24 AM, Tei oscar.vi...@gmail.com wrote: On 27 July 2012 12:53, Peter Coombe thewub.w...@googlemail.com wrote: This is one of the aims of the planned 'Athena' skin: https://www.mediawiki.org/wiki/Athena Pete / the wub Very interesting. Looks very good already. On 27 July 2012 12:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ Ouch. This website is aligned to the left, and designed for a fixed width of 1024px. *reads content* Yet again, we remember that HTML is liquid. Is supposed to be, wen is made fixed, is because compromises. On 27 July 2012 12:08, David Gerard dger...@gmail.com wrote: On 27 July 2012 11:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ http://blog.tommorris.org/post/21073443312/introducing-awfulness-js HTML 3.2 is looking better every day ... Infinite scrolling is not always evil. If you need to show a PDF document as a list of 200 high resolution JPG files. You can make the page height the resulting height if all the jpg where downloaded. But only download the JPG the user is looking at. If you try the naive approach,and create a html that links with img all the 700KB jpg files, the page will chocke for most users, because will ask for too much bandwidth too quick. And maybe the users only need to look at the first page, to confirm is interesting (maybe are books, and is the wrong book, or in the wrong language ). http://es.scribd.com/doc/6457786/Godel-Escher-Bach-by-Douglas-R-Hofstadter- By making a document become a computer program, we probably lose the ability to garantee it will end rendering before the end of the existence of the universe. But is often a good tradeoff. -- -- ℱin del ℳensaje. ___ 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] Criteria for serious alternative
On Thu, Jul 26, 2012 at 11:36:50PM -0700, Rob Lanphier wrote: On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis fai...@wikimedia.orgwrote: My understanding of the process was that we would collect a broad set of arguments/ideas/proposals and people would be later assigned to the task of evaluating them and proposing a viable solution and a migration path (or not, and propose that we stay with Gerrit). Yes, we're seeking a broad range of proposals. However, proposals is the key word. That means looking the requirements, reading the website and matching against those requirements, and stitching together something that at least looks good on paper. I'm not expecting anyone to set up a prototype, but I am asking that, given how long we've been talking about this, that we narrow down our options a bit to the things that we know are worth looking at rather than (still, a year later) having the have you looked at this? discussion again. I think GitLab looks promising but I'm unable to judge it against all of our requirements just from the online demo and without spending some amount of time on it. I just put some pros and cons as I see them to the Wiki page and hope it can be considered. Regards, Faidon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Captcha for non-English speakers II
2012/7/26 Platonides platoni...@gmail.com: Thet don't need to read English. They just need to type the letters they see on the image. Sure, you can have a small advantage if you know what letters could make a valid English word (or if you have the captcha dictionary installed), but a Brazilian which can read wikipedia should have no problems typing the captcha. If that is the case, why don't we change the CAPTCH for random letters? -- Everton Zanella Alvarenga (also Tom) Wikimedia Brasil Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wiki-research-l] request for Git statistics (or, don't stand back, I don't know regular expressions) (Wiki-research-l Digest, Vol 83, Issue 13)
On 07/24/2012 08:09 PM, Federico Leva (Nemo) wrote: Sumana Harihareswara, 24/07/2012 22:47: Ohloh would sure be a nice resource - I'm not sure how to get it fixed exactly, but please feel free to poke around, tell Ohloh where our new repository is, and try to get it fixed. Sorry, it's a low priority for me right now, but you have my authorization to try to get it fixed. The new repo for core was already there, but extensions were missing; I've now added them. https://www.ohloh.net/p/mediawiki (Some seem to partially disagree, by the way.) Thanks for stepping up and improving our Ohloh listing, Nemo! I hope others can help you in figuring out and resolving any contradictions. By the way, the WMF analytics team is working on some new analysis tools for our use of Gerrit but it's still very rough. https://gerrit.wikimedia.org/r/gitweb?p=analytics/gerrit-stats.git;a=summary is the repository to follow (https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core,n,z). Yes, we have big hopes in this! :) Nemo A note from Felipe Ortega that I got permission to forward onlist: Hi Sumana. I see that you have solved your request. I'm not sure if you know the toolset from my current research group for extracting and analyzing data from Git, as well as for other version control systems: http://git.libresoft.es/cvsanaly In fact, despite the name it supports CVS, SVN and Git. Here you can find a glimpse of the type of data that it can generate: http://git.libresoft.es/cvsanaly/tree/db/cvsanaly_model.svg We also have another tools for analyzing issue tracking systems (Bugzilla, SF.net, Allura, GitHub, JIRA, and Launchpad, so far). http://git.libresoft.es/bicho I'm not sure but they could probably help you monitor project resources and solve these kind of questions. My current group at URJC has started a spinoff based on these services, and they are already producing some interesting stuff for clients like Samsung (for their network of partners in Android) or OpenStack. Here is a mockup (they are using envision.js): http://gsyc.es/~jgb/repro/2012-akademyes-kdevelop/swscopio.html Well, hope this helps. Felipe. -- 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] Criteria for serious alternative
On Jul 27, 2012 6:58 AM, Chad innocentkil...@gmail.com wrote: 1) Personal dashboards will now be private -- the proper way to query someone's work is the owner: query in the search box. As MZ and I found out last night, this is not the case. An owner: search only finds changes that person *started*, so it doesn't find changes by others they've contributed patchsets to. Searching for an e-mail address does get all changes someone's been involved in (even if they only comment on the change), I believe it's equivalent to reviewer:. But this is all far from obvious and took me a while to figure out, people who haven't used Gerrit before don't really stand much of a chance there. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Jul 27, 2012 7:17 AM, Faidon Liambotis fai...@wikimedia.org wrote: I think GitLab looks promising but I'm unable to judge it against all of our requirements just from the online demo and without spending some amount of time on it. I just put some pros and cons as I see them to the Wiki page and hope it can be considered. I would also like Gitlabs to be considered, so I'll poke at that wiki page later. I may or may not have time to play with it before Monday. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Jul 27, 2012 1:11 AM, Antoine Musso We have disallowed branch creation and merging for now, that can definitely be opened up. Chad recently opened the sandbox reference and we have a few of them: remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox This is a great feature, but I think most people realize it exists. Was it ever publicized widely? Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On 2012-07-27 23:52, Jon Robson wrote: The Wikipedia mobile site is being made mobile first using responsive design techniques. The plan is for it to eventually mature into a responsive Athena skin that can also be used on desktop. Any idea about when the responsive Athena skin might be ready? 1 month, 3 months, a year? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On 07/27/2012 11:34 AM, John Elliot wrote: On 2012-07-27 23:52, Jon Robson wrote: The Wikipedia mobile site is being made mobile first using responsive design techniques. The plan is for it to eventually mature into a responsive Athena skin that can also be used on desktop. Any idea about when the responsive Athena skin might be ready? 1 month, 3 months, a year? Please note that this conversation might also be cross-posted to or continued on our design mailing list: https://lists.wikimedia.org/mailman/listinfo/design -- 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] Criteria for serious alternative
On Fri, Jul 27, 2012 at 11:33 AM, Roan Kattouw roan.katt...@gmail.com wrote: On Jul 27, 2012 1:11 AM, Antoine Musso We have disallowed branch creation and merging for now, that can definitely be opened up. Chad recently opened the sandbox reference and we have a few of them: remotes/gerrit/sandbox/apramana/gsoc remotes/gerrit/sandbox/demon/foo-bar remotes/gerrit/sandbox/devunt/oauth remotes/gerrit/sandbox/ori/hacks They are actual branch we can most definitely merge -no-ff back in master. http://www.mediawiki.org/wiki/Gerrit/personal_sandbox This is a great feature, but I think most people realize it exists. Was it ever publicized widely? I sent out an e-mail announcing it: Personal sandbox space in Gerrit [0] It was also documented on-wiki: https://www.mediawiki.org/wiki/Gerrit/personal_sandbox -Chad [0] http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/061584.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On 27 July 2012 16:35, Sumana Harihareswara suma...@wikimedia.org wrote: Please note that this conversation might also be cross-posted to or continued on our design mailing list: https://lists.wikimedia.org/mailman/listinfo/design Without joining a whole other list, can I just ask what attention is being paid to people less connected than San Francisco geeks with iPads? Editing Wikipedia is presently annoyingly slow on a 1Mbps connection and pretty much unfeasible on dialup, for example. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
This would be best answered by Brandon.From a personal point of view if the mobile site still looks like a mobile site in a desktop browser at the start of next year I will be somewhat disappointed with myself. I personally believe that mobile is the likely method for accelerating athenas development as there are less blockers to do that. A lot of the existing bottle neck from my perspective is due to a lack of volunteer developers in the many mobile projects which slows important things like this down. Aside from the new design we are also planning some cool stuff for Wiki loves monuments with image uploading via mobile phones to commons. Poke me off list if you are keen to give time/expertise to help accelerate important initiatives like this. :) On Jul 27, 2012 8:34 AM, John Elliot j...@jj5.net wrote: On 2012-07-27 23:52, Jon Robson wrote: The Wikipedia mobile site is being made mobile first using responsive design techniques. The plan is for it to eventually mature into a responsive Athena skin that can also be used on desktop. Any idea about when the responsive Athena skin might be ready? 1 month, 3 months, a year? ___ 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] Criteria for serious alternative
Le 27/07/12 15:42, MZMcBride a écrit : I don't think it's fair to say that my posts have been unconstructive. I've tried to present actual problems (such as the lack of an authors list) that inhibit being able to effectively use Gerrit. snip To clarify, I was mostly ranting about the form. Your posts are definitely constructive and you are a huge asset to all the tech team by constantly reporting what is wrong and opening bugs. So keep please doing that :-] -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
I did mention how Android used a homemade tool to do the reviews. It was introduced to me by a friend who is doing Android development for mobile phone companies. At first I was like: what about the existing google code or github? Then he explained me their pre commit workflow and it made me sure we wanted to use that. I think Ryan met the OpenStack folks who are using Gerrit. That probably convinced him it was the right tool for us too. Actually, we started using Gerrit for Ops before OpenStack switched to it. It's just a happy coincidence. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride z...@mzmcbride.com wrote: Antoine Musso wrote: MZ, Do you even have a labs account? Your continuous rants are far from being constructive and makes everyone lose their time. Nope. I looked at getting one once or twice, but the process seemed too bureaucratic and I ended up walking away. I imagine I'll make one once self-registration becomes possible. Give me a break. You fill out a request that asks for like 4 pieces of information, then (usually the same day) someone creates an account for you, which sends you a password by email. It's seriously like 3 clicks. This process is about 17234872748 times less bureaucratic then the svn request process was. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride z...@mzmcbride.com wrote: For what it's worth, I think Ryan makes a compelling case for sticking with Gerrit (and I'm still not convinced that another switch would do more good than harm). I'm still deeply worried about the ability to use and improve Gerrit. It would be horribly painful to see all of the work switching from SVN to Git (a large portion of which was intended to allow easy code contributions) go to waste because this particular Git front-end has scared everyone away. For what it's worth, this is pretty much exactly where I'm at right now. In spite of my defense of Gerrit, I'm not blind to it's manifold deficiencies in its current form. In addition to the problems for new volunteer contributors, there's a steep learning curve for new employees. I'm also worried about the steep learning curve anyone from our community (myself included) would have in getting set up to improve Gerrit through writing patches and plugins, though I'll take Chad at his word that it's really not as bad as many of us fear. But, I'm also still not convinced that another switch would do more good than harm. I think our best mitigation strategy is to do as good a job as we possibly can integrating Gerrit with GitHub, combined with other improvements to Gerrit. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 1:29 PM, Rob Lanphier ro...@wikimedia.org wrote: I'm also worried about the steep learning curve anyone from our community (myself included) would have in getting set up to improve Gerrit through writing patches and plugins, though I'll take Chad at his word that it's really not as bad as many of us fear. I wrote a new plugin last night and pushed it today: https://gerrit-review.googlesource.com/#/c/37030/ It took like...an hour? Yay for me ;-) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
Chad wrote: Also, if anyone tells me that upstream is not active enough, I ask you to please look at a commit I made 2 days ago[0]. I know it wasn't earth- shattering, or even really important. What was important, is that it was reviewed and merged in *less than a minute* without any action on my part. All upstream contributions receive quite a bit of feedback, and things get merged into master every single day. I talk with the Gerrit guys constantly, and they've been nothing but supportive and helpful in both my questions and helping to resolve our issues. That made me go to some bugs I experienced at the beginning, and look if they were thus fixed or not. Issue 899:Tab to password field doesn't work if diff page is in background Filed: Apr 7, 2011 - http://code.google.com/p/gerrit/issues/detail?id=899 The bug is still open, although it got fixed. Maybe independently, perhaps unexpectedly due to rewriten code. It took ~1 year to fix since being filed. Issue 1300: No history of removal actions Filed: Mar 25, 2012 - http://code.google.com/p/gerrit/issues/detail?id=1300 Pristine bug. Bug 35468 https://bugzilla.wikimedia.org/show_bug.cgi?id=35468 Filed 2012-03-25 - Still happening. The funny thing is that it is happening on gerrit.wikimedia.org but not on https://gerrit-review.googlesource.com or https://android-review.googlesource.com So although they may be very responsive to patches, it may not be so easy to get the bugs solved (other than doing so ourselves, which as said, is not simple). Just as a minor nitpick--those dashboards aren't meant to be viewed by anyone other than the author themselves (which is why it's the main page when you login, as well as the default page for My - Commits). Which is really annoying when you don't start from the home page. If I'm signing in from a change, that's because I want to comment/review on that change, not to go to a dashboard where it isn't even listed. Please do. I file every bug upstream as well, after it's been filed in our BZ. Sure. https://bugzilla.wikimedia.org/show_bug.cgi?id=38760 A quick note on the search field: it's super-powerful. I know I've pointed at the docs before, but I really encourage you to read them[0] if you're the type of user who likes doing these sorts of interesting queries. Also, in the merge queue for upstream right now (I'm praying it makes it into 2.5 before the branch) is search suggestions [1]. This should make it wayyy easier to find things you're looking for. I don't feel comfortable with it. Too much magic, probably. It would benefit from having an interace like bugzilla advanced search, even if it gets coverted to the operators. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On Fri, Jul 27, 2012 at 8:47 AM, Jon Robson jdlrob...@gmail.com wrote: This would be best answered by Brandon.From a personal point of view if the mobile site still looks like a mobile site in a desktop browser at the start of next year I will be somewhat disappointed with myself. +1 I personally believe that mobile is the likely method for accelerating athenas development as there are less blockers to do that. We should be looking at Athena (and other projects like it) as guidance for how were going to approach contribution projects on mobile. Our focus for the next year is to not just grow the readership base but to also grow the contributor base. We've never had as many eyes on Wikipedia as before who can't contribute. Mobile users can't be second class citizens within the Wikimedia projects. We have to build all new pipelines on mobile devices to make this happen. These contributor methods may look drastically different then their desktop counterparts. Responsive design is an interesting technique for layout but it breaks down for functionality. A mobile phone, a tablet, and a desktop/laptop are used very differently. Mimicking the exact same functionality means your failing to understand what's best for each device. A lot of the existing bottle neck from my perspective is due to a lack of volunteer developers in the many mobile projects which slows important things like this down. Aside from the new design we are also planning some cool stuff for Wiki loves monuments with image uploading via mobile phones to commons. Poke me off list if you are keen to give time/expertise to help accelerate important initiatives like this. I'm going to re-iterate what Jon said here. We have numerous projects going on now and we've been actively mailing, blogging, and tweeting to get new testers/developers/etc. Were always eager to get more people involved. If you need to catch up with what were working on just check the mobile projects pages. http://www.mediawiki.org/wiki/Mobile --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier ro...@wikimedia.org wrote: I think our best mitigation strategy is to do as good a job as we possibly can integrating Gerrit with GitHub, combined with other improvements to Gerrit. One thing I don't think has been explicitly said yet, although Brion hinted at it early on is the nature of the gerrit-github integration. Gerrit serves the required workflow well for things like core and key extensions and puppet, so having changes made via gerrit reflected in a github view is great for outsiders to explore and experiment. But it would also be great, especially for certain types of community contributions, if we could approve pull requests from github and have those reflected in gerrit. I realize this is all hand-wavy and stuff, but as Brion pointed out, it's all git. With some thought behind the design, a two-way integration between gerrit and github seems like it would be possible and useful. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
I wanted to get in a couple responses to Daniel, as well as try to make sure the conversation doesn't die. Obviously having a lead person in the OAuth2 process leave may effect what we want to implement. Or may spawn a new standard in the near future. But I hope we can still move ahead with laying the foundation for allowing other entities and applications to work with mediawiki and WMF sites, and specifically make sure that third parties can interact with WMF sites in a way that is more secure than currently possible. From the start of the OAuth idea I've been thinking we should handle the code in an abstract way. I definitely agree with you there, although deciding which functionality is common is obviously the tricky part. Where we draw that line can greatly effect the effort that is required to implement, so I want to make sure we draw it appropriately. I think recognizing that a user's session may have a different set of permissions from the permissions that their group membership gives them definitely falls into that category. Keeping track of the concept of external entities (whether it's a university serving SAML, or an app developer using oauth) may also fall into this category. Thoughts from other developers? - I started thinking that every user instance should have some sort of -getApplication()/-getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc... I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store etc. But it would be good to hear from other developers if they have thoughts on it? - To top all this off we could potentially also make a special built-in Import application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person. I hadn't heard other people mention tracking edits by Import or the Installer, but if there's support for that type of thing, then I agree, this might be a good place to include it. What does everyone think of this idea? Hopefully the lack of response was due to everyone recovering from wikimania instead of lack of enthusiasm for OAuth! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon cmcma...@wikimedia.org wrote: On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier ro...@wikimedia.org wrote: I think our best mitigation strategy is to do as good a job as we possibly can integrating Gerrit with GitHub, combined with other improvements to Gerrit. One thing I don't think has been explicitly said yet, although Brion hinted at it early on is the nature of the gerrit-github integration. Gerrit serves the required workflow well for things like core and key extensions and puppet, so having changes made via gerrit reflected in a github view is great for outsiders to explore and experiment. But it would also be great, especially for certain types of community contributions, if we could approve pull requests from github and have those reflected in gerrit. I realize this is all hand-wavy and stuff, but as Brion pointed out, it's all git. With some thought behind the design, a two-way integration between gerrit and github seems like it would be possible and useful. Yes, I agree wholeheartedly. The main reason I've been holding off on doing the replication yet is that the replication system was split off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it up twice. Once we've got 2.5 running, this will become a *top* priority for me in our Gerrit setup. Pulling stuff back in is probably doable (and I've heard rumors it's been done), but will require more investment. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
Yes, I agree wholeheartedly. The main reason I've been holding off on doing the replication yet is that the replication system was split off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it up twice. Once we've got 2.5 running, this will become a *top* priority for me in our Gerrit setup. Pulling stuff back in is probably doable (and I've heard rumors it's been done), but will require more investment. -Chad Not sure if anyone has mentioned this yet or not, but Gerrit 2.5 is getting pretty close to shipping too, so the wait shouldn't be too long. Skimming through their discussion on Google Groups [1] it appears as though as of July 11th there have been talks of starting releasing the RC versions of Gerrit 2.5. Not sure how long they usually end up staying in the RC stage before an actual release, but I can't imagine it is long. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
Forgot the link... [1] https://groups.google.com/forum/#!topic/repo-discuss/ZczND3xgtaw Sorry about that, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Captcha for non-English speakers II
I think that making Russian, Korean and Arabian captcha is really bad idea. English keyboad layout is installed by default in all operation systems, as far as I know. Moreover very interesting problems can appear if this feature would be implemented. Who will decide what captcha language is used? We can look at user IP address - then sometimes the foreigners will be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus assuming that every person who knows Ukrainian has the Ukrainian keyboard layout, which is not true. I think that the assumption that everyone in the internet is able to print English letters loking at their noised example is not very bold assumption. 26.07.2012 17:53 пользователь Everton Zanella Alvarenga ezalvare...@wikimedia.org написал: Hi all, how are you? I'd like to know about the possibility of solving an old issue with CAPTCHA for Wikipedias in languages other than English. This bug https://bugzilla.wikimedia.org/show_bug.cgi?id=5309 was created in 2006. There is a discussion here about having CAPTCHA in other languages from February 2012 http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/51951/ but it seems there was no conclusion. After working on campus with new editors in Brazil, I've checked this is a real obstacle, since most people here cannot ready English at all. I'd like to know if there are plans to solve this issue - I hope I don't sound rude, maybe this can be a minor issue when we don't see the difficulties people from a different place can face. I think this is important for Wikipedias other than the English one (just read people comments in the bug) and we can be loosing new contributors because of their first impressions. Thanks, Tom -- Everton Zanella Alvarenga (also Tom) Wikimedia Brasil Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 2:08 PM, Derric Atzrott datzr...@alizeepathology.com wrote: Yes, I agree wholeheartedly. The main reason I've been holding off on doing the replication yet is that the replication system was split off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it up twice. Once we've got 2.5 running, this will become a *top* priority for me in our Gerrit setup. Pulling stuff back in is probably doable (and I've heard rumors it's been done), but will require more investment. -Chad Not sure if anyone has mentioned this yet or not, but Gerrit 2.5 is getting pretty close to shipping too, so the wait shouldn't be too long. Skimming through their discussion on Google Groups [1] it appears as though as of July 11th there have been talks of starting releasing the RC versions of Gerrit 2.5. Not sure how long they usually end up staying in the RC stage before an actual release, but I can't imagine it is long. Actually, a discussion started this morning again about what needs doing before the branch happens. The release manager for this cycle listed a couple of bullet points. That thread is here[0]. In general, the RC cycle is pretty quick--there's no firm rules, generally lasts a couple of weeks while any major remaining blockers are ironed out. I imagine we'll be seeing 2.5 final by late August at the latest. -Chad [0] https://groups.google.com/d/msg/repo-discuss/rxHwJJ2X9Ug/f7_6qMcsRYMJ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On Jul 27, 2012, at 8:47 AM, Jon Robson jdlrob...@gmail.com wrote: This would be best answered by Brandon.From a personal point of view if the mobile site still looks like a mobile site in a desktop browser at the start of next year I will be somewhat disappointed with myself. I, too, shall +1 this. I personally believe that mobile is the likely method for accelerating athenas development as there are less blockers to do that. And again, another +1. Mobile allows us to do radical rethinks - both by choice and by necessity. In fact, it was thinking about how we were going to solve some information architecture problems in the mobile space that led to much of the reasoning behind the necessity for Athena in the first place. A lot of the existing bottle neck from my perspective is due to a lack of volunteer developers in the many mobile projects which slows important things like this down. Aside from the new design we are also planning some cool stuff for Wiki loves monuments with image uploading via mobile phones to commons. Poke me off list if you are keen to give time/expertise to help accelerate important initiatives like this. :) Athena's timeline is murky. We are still very much in the design iteration phase as far as layout and interaction goes. However, the Agora project - a Foundation-specific style guide - is pretty far along and should be completed soon. --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 10:59 AM, Chad innocentkil...@gmail.com wrote: On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon cmcma...@wikimedia.org wrote: I realize this is all hand-wavy and stuff, but as Brion pointed out, it's all git. With some thought behind the design, a two-way integration between gerrit and github seems like it would be possible and useful. Yes, I agree wholeheartedly. The main reason I've been holding off on doing the replication yet is that the replication system was split off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it up twice. Once we've got 2.5 running, this will become a *top* priority for me in our Gerrit setup. Yay! Pulling stuff back in is probably doable (and I've heard rumors it's been done), but will require more investment. Cordova/PhoneGap hosts their primary repositories on Apache infrastructure, but keeps github mirrors and accepts pull requests through them. You don't actually need special tooling; they do it pretty bare-bones by having the accepter pull the branch, merge and push it themselves: http://wiki.apache.org/cordova/CommitterWorkflow Taking a pull request, cleaning it up, and popping it into gerrit for its final verification +2 is at least no worse than taking a patch from Bugzilla or direct mail and sticking it in -- but should preserve the authorship info in the commit. If we can devise tooling to make it even easier (paste in a pull request's URL and say go), that could be spiffy though. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Captcha for non-English speakers II
Maybe present three or four different capcha's with different scripts, requiring only one to be filled out? On Fri, Jul 27, 2012 at 8:09 PM, Yury Katkov katkov.ju...@gmail.com wrote: I think that making Russian, Korean and Arabian captcha is really bad idea. English keyboad layout is installed by default in all operation systems, as far as I know. Moreover very interesting problems can appear if this feature would be implemented. Who will decide what captcha language is used? We can look at user IP address - then sometimes the foreigners will be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus assuming that every person who knows Ukrainian has the Ukrainian keyboard layout, which is not true. I think that the assumption that everyone in the internet is able to print English letters loking at their noised example is not very bold assumption. 26.07.2012 17:53 пользователь Everton Zanella Alvarenga ezalvare...@wikimedia.org написал: Hi all, how are you? I'd like to know about the possibility of solving an old issue with CAPTCHA for Wikipedias in languages other than English. This bug https://bugzilla.wikimedia.org/show_bug.cgi?id=5309 was created in 2006. There is a discussion here about having CAPTCHA in other languages from February 2012 http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/51951/ but it seems there was no conclusion. After working on campus with new editors in Brazil, I've checked this is a real obstacle, since most people here cannot ready English at all. I'd like to know if there are plans to solve this issue - I hope I don't sound rude, maybe this can be a minor issue when we don't see the difficulties people from a different place can face. I think this is important for Wikipedias other than the English one (just read people comments in the bug) and we can be loosing new contributors because of their first impressions. Thanks, Tom -- Everton Zanella Alvarenga (also Tom) Wikimedia Brasil Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Captcha for non-English speakers II
On 27.07.2012, 22:09 Yury wrote: I think that making Russian, Korean and Arabian captcha is really bad idea. English keyboad layout is installed by default in all operation systems, as far as I know. Moreover very interesting problems can appear if this feature would be implemented. Who will decide what captcha language is used? We can look at user IP address - then sometimes the foreigners will be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus assuming that every person who knows Ukrainian has the Ukrainian keyboard layout, which is not true. I think that the assumption that everyone in the internet is able to print English letters loking at their noised example is not very bold assumption. Even funnier: imagine a Eeuropean trying to just read a Chinese captcha:) -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp cste...@wikimedia.org wrote: I wanted to get in a couple responses to Daniel, as well as try to make sure the conversation doesn't die. Obviously having a lead person in the OAuth2 process leave may effect what we want to implement. Or may spawn a new standard in the near future. But I hope we can still move ahead with laying the foundation for allowing other entities and applications to work with mediawiki and WMF sites, and specifically make sure that third parties can interact with WMF sites in a way that is more secure than currently possible. From the start of the OAuth idea I've been thinking we should handle the code in an abstract way. I definitely agree with you there, although deciding which functionality is common is obviously the tricky part. Where we draw that line can greatly effect the effort that is required to implement, so I want to make sure we draw it appropriately. I think recognizing that a user's session may have a different set of permissions from the permissions that their group membership gives them definitely falls into that category. Keeping track of the concept of external entities (whether it's a university serving SAML, or an app developer using oauth) may also fall into this category. Thoughts from other developers? Yeah, I think my random OAuth brainstorming reflects this too: https://www.mediawiki.org/wiki/User:Dantman/OAuth/Brainstorm Authorizations have an interface to return the rights that the user has in the authorization. While this interface is present in the code it doesn't show up anywhere inside the generic part of the database for authorizations. Instead it's handled at the plugin implementation level. In this case auth codes, access tokens, and refresh tokens have scope information and that is used by the OAuthAuthorization to return rights information. - I started thinking that every user instance should have some sort of -getApplication()/-getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc... I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store etc. But it would be good to hear from other developers if they have thoughts on it? Separate user rows for OAuth? - To top all this off we could potentially also make a special built-in Import application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person. I hadn't heard other people mention tracking edits by Import or the Installer, but if there's support for that type of thing, then I agree, this might be a good place to include it. What does everyone think of this idea? Hopefully the lack of response was due to everyone recovering from wikimania instead of lack of enthusiasm for OAuth! -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Captcha for non-English speakers II
2012/7/28 Max Semenik maxsem.w...@gmail.com: On 27.07.2012, 22:09 Yury wrote: I think that making Russian, Korean and Arabian captcha is really bad idea. English keyboad layout is installed by default in all operation systems, as far as I know. Moreover very interesting problems can appear if this feature would be implemented. Who will decide what captcha language is used? We can look at user IP address - then sometimes the foreigners will be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus assuming that every person who knows Ukrainian has the Ukrainian keyboard layout, which is not true. I think that the assumption that everyone in the internet is able to print English letters loking at their noised example is not very bold assumption. Even funnier: imagine a Eeuropean trying to just read a Chinese captcha:) Funny as it may be, this is a non-problem. You can easily have a give me an English CAPTCHA link... And that would be one more step for a robot to learn, that is, one more (thin) defence line. Strainu ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Jul 26, 2012, at 7:04 PM, MZMcBride z...@mzmcbride.com wrote: Rob Lanphier wrote: A few of us are planning to meet Monday afternoon to figure out exactly what the rest of the process looks like, so that first deadline is going to be very important for understanding how many options we're truly considering. Well, at least you're being open about not being open. That's funny, because my experience is the exact opposite: this meeting is not in my calendar and I breathed a sigh of relief! It's somewhat ironic that you have a group of people who regularly champion the virtues of open source software (you can hack the code!) who have picked a software solution that's (apparently) nearly impossible to modify. Even eliminating Gerrit's vomit color scheme would be a vast improvement, but as I understand it, even basic CSS changes are a no-go with Gerrit. Gerrit has templating support so basic CSS changes are not difficult and require no pushes to upstream Gerrit. Delta one strange thing in that the load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are in fancier scripting UI that requires delving into GWT to get done. Chad mentioned that virtually nobody has played with either yet. I'm lost as to how Gerrit was ever considered an option previously and how it's still an option on the table today, given its apparent inflexibility. Say what you will about MediaWiki's CodeReview extension, but on its worst day, it never garnered as much resentment as Gerrit. The wiki page outlines exactly what went into the decision. For instance, I like Phabricator. However very few of the requirements listed when this was discussed (in March) were in Phabricator so I understand why Gerrit was chosen even if I have a personal dislike for it. Phabricator has a high velocity of new features and support (actually about 2x Gerrit) and that is now changes. However, even so, that isn't the case (yet). Also, consider that even if that is the case, it's neither Features engineers nor the community will be inplementing/maintaining whatever solution is used. The maintainers will be in Platform and Ops. Now we can argue over whether the wiki page's criterias were the right ones. (For instance, should the WMF adopt the Git/GitHub philosophy of un-gated reviews?) But since those criteria come from the practical reality on how code review is actually done and integrated currently, that's a different argument entirely to what code review tool is best for how we currently use it. Gerrit won simply because it is designed to work the same way we were currently working… warts and all. But the landscape is changing and it's time to re-evaluate if a course correction is in order. Hopefully this won't be the last (if only because I don't think any other system is going to beat Gerrit spec-for-spec ATM). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Criteria for serious alternative
On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay tc...@wikimedia.org wrote: Gerrit has templating support so basic CSS changes are not difficult and require no pushes to upstream Gerrit. Delta one strange thing in that the load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are in fancier scripting UI that requires delving into GWT to get done. Chad mentioned that virtually nobody has played with either yet. This is not what I said. I said injecting Javascript is possible as well, which Roan said he has experimented with before. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
Are you a Brandon plant trying to get us to resource Athena again? :-) On Jul 27, 2012, at 3:01 AM, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ ___ 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] OAuth, abstract implementation, and built-in unknown / internal / import applications.
On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen li...@nadir-seen-fire.comwrote: On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp cste...@wikimedia.org wrote: I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store etc. But it would be good to hear from other developers if they have thoughts on it? Separate user rows for OAuth? OAuth 2.0 has a scope field to let the client request an auth token with the scope of the permissions it is requesting, which is a space delimited list of scope strings, to which the server can respond with an auth token that includes that scope list, a different scope list, or an error.[1] I think creation of an OAuth token should result in the creation of a MediaWiki session, and that scope should be added to the session data. In our initial implementation, I think each of scope strings should correspond to MediaWiki permissions (i.e. mCoreRights in User.php). However, we should think ahead to the day when we might want to have something more fine grained than that. Rob [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier ro...@wikimedia.org wrote: On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen li...@nadir-seen-fire.comwrote: On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp cste...@wikimedia.org wrote: I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store etc. But it would be good to hear from other developers if they have thoughts on it? Separate user rows for OAuth? OAuth 2.0 has a scope field to let the client request an auth token with the scope of the permissions it is requesting, which is a space delimited list of scope strings, to which the server can respond with an auth token that includes that scope list, a different scope list, or an error.[1] I think creation of an OAuth token should result in the creation of a MediaWiki session, and that scope should be added to the session data. In our initial implementation, I think each of scope strings should correspond to MediaWiki permissions (i.e. mCoreRights in User.php). However, we should think ahead to the day when we might want to have something more fine grained than that. Rob [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3 No, I already know about scope. I was just confused what Chris was trying to describe when he grouped separate topics into one paragraph. OAuth 2 scope can actually apply to the auth code, refresh token, and access token separately. The auth code's scope defines the refresh token's scope. And the refresh token's scope is used when defining the access token's scope. But it's possible to use a refresh token to request an auth code with less permissions than what the refresh token has. I don't think 'session' will work in the context we currently use it in core. Authorizations, especially refresh tokens are persistent while session storage is ephemeral and can easily forget something we don't want it to forget. We also want to be careful about touching the session data at all. Besides the point that OAuth doesn't use cookies anywhere at all we want to be careful with the fact that we're probably going to need to support an OAuth + CORS environment where we want to erase all cookie and session data and pretend it doesn't exist even if the browser sends it. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Captcha for non-English speakers II
On 27/07/12 16:31, Everton Zanella Alvarenga wrote: 2012/7/26 Platonides platoni...@gmail.com: Thet don't need to read English. They just need to type the letters they see on the image. Sure, you can have a small advantage if you know what letters could make a valid English word (or if you have the captcha dictionary installed), but a Brazilian which can read wikipedia should have no problems typing the captcha. If that is the case, why don't we change the CAPTCH for random letters? You should probably ask Neil Harris, the author of the captcha generator we use. from his 06/02/2011 mail: The wordlists themselves need not be secret: they are only needed to create easily-typed strings that are sufficiently large in number to provide a moderate challenge to brute force guessing. I have added a random captcha at http://test.wikipedia.beta.wmflabs.org/ You can try adding urls at http://test.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Pageaction=edit and http://en.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Sandbox for comparing the presented captchas. (yes, testwikibeta is quite broken right now, but the captchas show) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
