Wikitech-l July 2012

wikitech-l@lists.wikimedia.org

128 participants
119 discussions

8 simple ways for improving Gerrit
by Chad 28 Jul '12

28 Jul '12

Hi everyone, We've wanted to change the Gerrit UI to be less ugly for quite awhile, and I think a good first step is getting rid of the puke green/yellow color schemes. Gerrit has the ability to change these colors without using CSS-- it's done with the "theme" configuration[0]. I'm awful at choosing these sorts of things, so I thought I would open it up to the list for a bit of bikeshedding to come up with some colors we can use. Specifically, there's 5 colors we can change *right now* and that I'd love to get some input on what to change them to. These 5 are: 1) backgroundColor -- pretty self explanatory, default is #FCFEEF for anonymous users and #FFFFFF for logged in users. 2) topMenuColor -- the color in the top menu area, the puke green, #D4E9A9 3) textColor -- self explanatory, default is #000000 4) trimColor -- used for section headers and such, same green as topMenuColor by default 5) selectionColor -- the cream-yellow color used when you're highlighting a given field/button/etc in Gerrit, color is #FFFFCC Additionally, there's 3 more colors that we'll be able to customize starting with 2.5, so it's worth keeping them in mind (and maybe going ahead and picking colors for them too): 5) changeTableOutdatedColor -- That glaring red that shows up in the dependencies field when a dependency is outdated, default #F08080 6) tableOddRowColor -- with 2.5, we can do alternating colors for the change listings, making it easier to read. By default, transparent. 7) tableEvenRowColor -- complement of above We can test these all on the labs instance of Gerrit[1], and in fact RobLa and I tried some colors awhile back (but neither of us are designers). If anyone wants access to the instance so they can play with it, please ping me and I'll be happy to add you. Thanks for input everyone :) -Chad [0] https://gerrit.wikimedia.org/r/Documentation/config-gerrit.html#_a_id_theme… [1] http://gerrit-dev.wmflabs.org/

2 3

Responsive web design
by John Elliot 28 Jul '12

28 Jul '12

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/

11 14

OAuth, abstract implementation, and built-in unknown / internal / import applications.
by Daniel Friesen 28 Jul '12

28 Jul '12

From the start of the OAuth idea I've been thinking we should handle the code in an abstract way. ie: Applications and Authorizations should be something MediaWiki implements internally in an abstract way. And then we write an OAuth extension that extends this and lets you authorize OAuth 2 clients. Things like mass-reverts by application, authorization revocation, and displaying what application was responsible for an edit would be handled from within MediaWiki abstractly instead of being OAuth specific. -- Skip for TL;DR version -- Originally I had some ideas like implementing some custom auth system for other wiki. Implementing OAuth 1.0 in addition to OAuth 2 (at the time it appeared signatures had disappeared and OAuth 2 was worse than OAuth 1 in some cases). And supporting something along the lines of Google's application passwords. I'm not focused on that right now. But I still think it would be a good idea to do. We don't know what'll happen in the future. Someone could write an OAuth 3 that is also not backwards compatible and we want to implement. Or someone could come up with a different standard that does things in a more secure way or supports discovery in a very well thought out way. So doing things abstractly will let us add those as things go along without any trouble. Additionally doing this abstractly allows us to test just small components of the system in an isolated way without needing a whole OAuth stack. -- / continue reading from here -- I had an interesting thought when I was thinking about how we'd do this abstractly. - 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... - To make things easy on code I thought that ->getApplication() should always return an Application instance so you don't have to null test it. Under that idea MediaWiki itself would have a dummy Application which would be tied to every standard edit. The database would probably even reflect this. After this I started thinking of separating things a bit more. - By default every blandly created User instance would be tied to an "Unknown" application. - While when a user instance is setup using session data we assign the "Internal" application to it. - As a result of this all dummy edits made through internal code would end up associated with an "Unknown" application instead of the "Internal" one. In other words, we'd finally have a formal way to find system made edits like the initial Main Page edit populated by the installer. That would be an "Unknown" application. The same would go for various extensions that made dummy edits. - 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. What does everyone think of this idea? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

3 4

Criteria for "serious alternative"
by Rob Lanphier 28 Jul '12

28 Jul '12

On Thursday, July 26, 2012, Faidon Liambotis wrote: > This is not to you specifically but as a general remark: there are > multiple other alternatives that have been mentioned besides Gerrit and > GitHub with a potential of getting the best of both worlds. I think it's > better to not polarize the discussion between the two most popular > options at this point and talk about all options. Nice segue into a topic that I've been meaning to get to. :) Right now, the serious alternatives seem to be: * Sticking with Gerrit (with GitHub integration) * Moving fully to GitHub * Moving to Phabricator (though the proposal is pretty thin right now) Nothing else has been advocated with a degree of seriousness as to warrant consideration at this point. That's not to say we're done with those options; if someone wants to put together a serious proposal, there's still a little time. However, in order to practically consider the alternatives, we need to have the serious proposals enumerated, and a credible plan for addressing any deficiencies. I've gone through and modified the criteria, splitting up the MUSTs from the SHOULDs: http://www.mediawiki.org/wiki/Git/Gerrit_evaluation Even the "sticking with Gerrit" section is currently thin on credibly meeting the criteria, so we'll have to beef up our stated plan for getting it up-to-snuff. Here's the timeline I'd like to propose: * July 30, noon PDT - reasonably complete draft sections need to be in place * August 1, 9am PDT - complete proposals due 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. Thanks Rob

13 35

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)
by Federico Leva (Nemo) 27 Jul '12

27 Jul '12

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.) > 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

2 1

"Laptop setup guide" for future Hackathons
by Asheesh Laroia 27 Jul '12

27 Jul '12

Hello, dear wikitech-ians, For the Hackathon, I (with some help!) prepared a laptop setup guide for getting MediaWiki installed, from start to finish, on Windows, Mac, and Linux. http://www.mediawiki.org/wiki/Hackathon/Laptop_setup It is somewhat unique in the world of MediaWiki install instructions in that: * It uses sqlite. * It is quite prescriptive -- it tells you what to do, rather than giving you many options. (This helps us avoid danger points -- for example, some people accidentally download Apache/PHP bundles with 5.3.1 still. To avoid that, we advise a specific bundle.) * It is targeted at people without any command line experience. * It is targeted at people without necessarily any experience with a text editor. I originally wrote it for the Wikimania Hackathon's newbie track, and it worked reasonably well there. Therefore, unlike most sets of "install MediaWiki", it's been 'play-tested'. I've copied it to here: http://www.mediawiki.org/wiki/Hackathon/Laptop_setup My own quibbles --------------- One of the big problems we experienced with this Laptop setup page was that it's not a great thing to do *first* -- it took some people way more than one hour. For some of the "Tasks" we put together for the Hackathon, you didn't need a local development environment for MediaWiki, and for others, you did but could live without getting git/gerrit going. Therefore, if a person wants to set up MediaWiki on their own machine without requesting Git/Gerrit access, then they don't have to go through all these steps. Also, there were a handful of problems we worked out in the Mac OS version of the documentation -- those are fixed now, though. By and large, I'm pretty happy with it. Next steps ---------- Here's my question for y'all: where do docs like this fit into the mediawiki.org install guides? Is there a person I should contact who maintains the main install guide, or should I just be some combination of 'bold' and respectful and try to weave it into the main documentation? (Doing that would be a pretty massive undertaking.) What I would like to see, honestly, is the following: https://www.mediawiki.org/wiki/Manual:Installation_guide has a few giant buttons: "Want to install MediaWiki on your web hosting?" which takes you to some docs that discuss PHP, SFTP, etc. "Want to install MediaWiki on your personal computer?" which takes you to something like Hackathon/Laptop_setup (Maybe other giant nav buttons?) Alternatively, we could just let my Hackathon/Laptop_setup guide sit where it is, and future Hackathons will just reference those, but the official install docs won't ever link there. (I think this would not be as good, but am curious to hear what y'all think.) -- Asheesh.

4 4

Re: [Wikitech-l] Problem with saving edits
by James Heilman 26 Jul '12

26 Jul '12

Loads the page in read mode and my changes have not been saved. -- James Heilman MD, CCFP-EM, Wikipedian The Wikipedia Open Textbook of Medicine www.opentextbookofmedicine.com

1 0

Re: [Wikitech-l] Problem with saving edits
by James Heilman 26 Jul '12

26 Jul '12

Yes I am using Chrome on a Windows machine. English Wikipedia is where I have had the problem. Sometimes when I hit save the text simply does not save and everything is as it was before I tried to make a change. I am always logged in when I edit. Typically occurs when I have cut and pasted stuff into the edit box. There are no error messages just no changes. Have not yet tested other browsers or computers. I was hoping someone else has had this problem already and thus it had been figure out :-) James Heilman

2 1

How to start and run a user group
by Sumana Harihareswara 26 Jul '12

26 Jul '12

http://www.mongodb.org/display/DOCS/Your+Go-to+Resource+for+Running+a+Mongo… There were people from 30 countries at the Berlin hackathon this year. It'd be cool if, by this time next year, there were 30 get-togethers to help MediaWiki administrators swap tips and talk about what's happening in MediaWiki development. You can do it. You can do a case study of "ways to improve your MediaWiki installation" at your local system administrators' or PHP meetup. You can look for interested techies near you who want a "helpathon." We can help. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

Serious alternatives to Gerrit
by Rob Lanphier 26 Jul '12

26 Jul '12

Hi everyone, It appears as though the discussion has continued apace for the Gerrit evaluation process: http://www.mediawiki.org/wiki/Git/Gerrit_evaluation Thank you everyone for chipping in so far. The current format is a mix of talk page and structured discussion, which seems ok for now. It would appear from reading this page that the only alternative to Gerrit that has a serious following is GitHub. Is that the case? Personally, it seems like Phabricator or Barkeep has the best chance of dislodging Gerrit, but those won't probably get serious consideration without a champion pushing them. Rob

28 75

← Newer
1
2
3
4
5
6
7
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2012