Hi,
It's recently come up in some of the Wikidata changes proposed to core to
start using some ORM-like interfaces for accessing this data[0]. Since we
don't use ORM-style access anywhere else in core, I figured it warranted
some wider discussion before we begin introducing the pattern.
Personally, I'm a big fan of consistency and since we don't use ORM
anywhere else, I'm hesitant to begin using a new design pattern here (and
I'm not entirely convinced why it's *needed*). On a more philosophical
level, I personally don't like ORM because I think it needlessly abstracts
data access in a more confusing way--but my personal feelings can be
forgotten if people think this actually makes more sense.
However, I may be in the minority here, and my fears are unfounded. I
would love some feedback from everyone about whether ORM in the
sites code (and more generally, in core) is a good idea.
Thoughts?
-Chad
[0] https://gerrit.wikimedia.org/r/#/c/14295/
Won't it be better to add a custom field for gerrit patchs to ease the
search of them and take the need to skim the whole thread to find a
comment with a link to gerrit patch?
I suggested it here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39399
we might have some benefits if we rethink the entire bug workflow.
> On 08/27/2012 01:59 PM, Marcin Cieslak wrote:
>> - user A posts a patch
>> - the bug gets "patch", "patch-need-review"
>> - user B posts a patch that is different and says
>> he does not like patch of A
>> - user B submits change to gerrit
>>
>> When "need-review" should be removed?
>
> User B should remove "need-review". Code in gerrit has its own review
> process and it shouldn't be necessary to keep the keywords in Bugzilla
> up to date. User B should make sure that the bug has a comment
> referring to his gerrit submission.
>
>> What if I believe that core ideas behind the
>> patch are wrong?
>
> Leave a comment with your thoughts. You could also remove the
> "need-review" keyword and, optionally, mark the patch as obsolete.
> Marking it as obsolete is a pretty strong statement, though.
>
>> What if I just think the implementation
>> should be improved?
>
> Remove the "need-review" and leave a comment with your suggestions.
> Directing the submitter to gerrit for future submissions is a good idea,
> too, but that might add another step that that makes future submissions
> improbable.
>
>> What it it's more or less okay?
>
> Remove the "need-review" keyword and direct the submitter to gerrit or
> submit it to gerrit on their behalf. Make sure you refer to the bug
> number in first line of the commit message (see
> https://gerrit.wikimedia.org/r/#/c/13855/ for an example). Other people
> will then have a chance to review it and it may be merged.
>
> If you don't have a gerrit account, apply for one or find someone who
> does to apply the patch.
>
>> Before I open a whole can of worms by asking a question
>> how do I relate those keywords to the Gerrit workflow
>> we have
>
> Oops! I guess I opened the can and not you!
>
> Mark.
>
>
>
Reproduced from the project blog [1]:
Hello Wikitech!
As the GSoC project period has come to a close, I want to give the
Wikimedia community an update on the status of my project to improve
MediaWiki’s watchlist feature.
Thus far, the project has added watchlist grouping, permissions to make
watchlists publicly viewable by other users, and a new raw watchlist page.
Although these features are still at an experimental phase, I would like to
solicit ideas from the greater Wikimedia community for a more detailed plan
in preparation for a Wikimedia deployment.
The primary component of the project yet to be realized is revamping the
user interface. I’ve done some tinkering with jQuery and Ajax as
implemented in MediaWiki, however I opted to focus on server-side
operations initially, so that client-side additions would not need major
changes later on.
I’m currently looking for other developers who would be interested in
collaborating on this project, especially UI designers. If there is a
specific feature or improvement you would like to see, please let me know –
you can adopt it or suggest someone who would be interested in working on
it with me.
Finally, there are several people I’d like to acknowledge: My mentor, Alex,
for always being there when I needed him; Reedy, Eranroz, and Nikerabbit
for being excellent, eagle-eyed debuggers; and Sumana and Greg for being
awesome GSoC project coordinators!
I truly enjoyed this unique opportunity to work with Wikimedia over the
summer. Working through GSoC has given me my first real form of paid work
experience in programming. It has shown me that the greatest challenge of
distance work is organizing people in the community who may be juggling
numerous other responsibilities. My advice for future GSoC students: manage
your time wisely, communicate early and often, and strike a balance between
independent and collaborative problem solving. I look forward to working
with Wikimedia and other open source projects in the future.
Best,
Aaron Pramana
[1] http://mw-watchlist.tumblr.com/
Hi, in the introduction to the Help page for the "Flagged Reviews" extension, it says the following:
"It is possible, however, to configure pages so that only revisions that are flagged to a certain level are visible when the page is viewed by readers" (http://www.mediawiki.org/wiki/Help:Extension:FlaggedRevs).
This would indeed seem to be one of the most basic functions of the extension. At he.wikisource the community has decided to change the installation so that only pages approved at the the highest level of quality will be shown as the default view, while all pages flagged at lower quality levels will show the current version as default.
Can anyone tell us if such functionality is indeed possible?
Dovi
A while back[1], I started a discussion about moving tarball maintenance
out of the Foundation. I have spent a little time since then talking to
Sam Reed about what is actually involved, but we're coming up on the 6
month mark since the last release and I need to start doing something if
I'm actually going to follow through.
I've started
https://www.mediawiki.org/wiki/Requests_for_comment/Tarball_maintenance
to help drive this. I would really like to get the next version of the
tarball out the door by November (6 months from the last release in May).
[1]
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/61638
--
http://hexmode.com/
Human evil is not a problem. It is a mystery. It cannot be solved.
-- When Atheism Becomes a Religion, Chris Hedges
https://bugzilla.wikimedia.org/34961
Niklas and Siebrand have already weighed in on this bug back in Mar,
and, indeed, it went away for a while.
Niklas said
We could make it the same as how it is in Special:Logs, removing
the first Username and not the username that is part of the message.
It seems like that would be better than the current situation. Is there
a reason that isn't done? It seems like this is turning into one of
those little paper-cut bugs[1] that annoy long-time Wikipedia editors.
Could someone update the bug?
[1] https://wiki.ubuntu.com/PaperCut
--
http://hexmode.com/
Human evil is not a problem. It is a mystery. It cannot be solved.
-- When Atheism Becomes a Religion, Chris Hedges
Is there any interest in having nightly snapshots of MediaWiki available?
I realize people could just use git, but this poses a problem for users
who are familiar with extracting, say, a .xip file, and making MediaWiki
work, but are stymied by the esoteric nature of git.
This would be similar to Mozilla's nightlies:
(http://nightly.mozilla.org/) and may also be a stepping stone for
people to get into development, or at least patch submission.
This all came up because I had the chance to provide a snapshot to help
solve a problem in 1.19
(http://thread.gmane.org/gmane.org.wikimedia.mediawiki/40011, shortened:
http://hexm.de/kt).
I used the make-release script
(http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-release/,
shortened: http://hexm.de/ku) and put the snapshot up at
http://mah.everybody.org/snapshots/.
I'm willing to set this up to run on wmflabs.org or on my own server if
there is interest. This may also be a good way to measure the "need"
for a point release -- for example, if the nightly starts including
fixes for annoying bugs that affect a lot of people, then a point
release is probably needed. (I'm looking at you, Bug #24985.)
--
http://hexmode.com/
Human evil is not a problem. It is a mystery. It cannot be solved.
-- When Atheism Becomes Religion, Chris Hedges
Tomasz Ganicz, 27/08/2012 13:27:
> Detailed information regarding Wikimedia Foundation's server's and
> network can be found here:
>
> http://wikitech.wikimedia.org/
Which is completely useless for any kind of high-level information, in
particular [[Server roles]] which is dead and has no replacement and
https://meta.wikimedia.org/wiki/Wikimedia_servers is outdated.
But you might dig http://wikitech.wikimedia.org/view/Presentations ,
it's also possible that some Wikimania presentations have been added
already.
Nemo
Meta discussions over community, Appreciation threads, GSoC wrapups,
Deployment threads, and orthogonal questions.
Lately wikitech-l seems to be almost void of one of the most important
categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread
dedicated to listing out things we'd like to see in MediaWiki or perhaps
would like to write ourselves.
Not really big things like VisualEditor, Wikidata, and Lua who have teams
of people within WMF working on them. But rather those other important
things a lot of us may want but always end up pushed to the side and
forgotten.
For me...
Before I list the small stuff here are 3 big projects right now I wish I
could work on but won't possibly have the time unless I find someone
willing to pay me enough to drop a normal job an dedicate my programming
time to writing things for MediaWiki:
- Gareth: It's not exactly a MediaWiki feature. But with the Gerrit
annoyances and talk about other review systems I've had a really good idea
how to do a review system right this time around. It would be nice to
spend a pile of time turning it into a system that we could actually use
for our code review.
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic implementation of actual OAuth (1&2) looks like a dark
dead-end. Rather than OAuth I'd like to write a new auth standard that
learns from all the good things and the mistakes made in both versions of
OAuth and takes note of all the things we really need. And then implement
it into MediaWiki and write a series of server and client libraries/sdks
so it's also easier to pick up than either OAuth.
- Machine-Learning based Anti-spam: Wikipedia has bots like ClueBot NG
dealing with spam. It would be nice to have machine-learning based
anti-spam built into a MediaWiki extension with a nice intuitive user
interface usable outside of WMF so all wikis can have great anti-spam.
Now some old and forgotten code topics:
- 404 routing: I'd like us to get to the point where we can set
ErrorDocument 404 /w/index.php and MediaWiki will automatically start
doing short urls, outputting 404 pages for you, and acting as an implicit
thumbnail handler.
- Title rewrite: Aaaaincient topic... updating our handling of the page
table and titles in general so that the case, whitespace, and all the
stuff in a title that just get's normalized away is correctly remembered.
So that [[iPod]], even though it's the same as [[IPod]] will always
display as "iPod" even in lists outside of the page itself such as
Special:Allpages
- Password reset tokens: It's unbelievable but we are STILL using
temporary passwords instead of reset tokens. Naturally this is less usable
and also lowers the security of our password reset system.
- An abstract revision system. The way we shove configuration into i18n,
i18n into articles, scripts and stylesheets into articles, and extensions
go and do the same. All just to get proper revisioning of things. Is
horrible. Not to mention the extensions that don't and rely on our logging
system which makes it harder to revert things. With all this together I'd
like to see an abstract system that lets extensions have their own
revision system outside of page content for whatever they need to do.
----
https://www.mediawiki.org/wiki/User:Dantman/Code_Ideashttps://www.mediawiki.org/wiki/User:Dantman/Abstract_Revision_Systemhttps://www.mediawiki.org/wiki/User:Dantman/Code_Ideas/PageLayoutshttps://www.mediawiki.org/wiki/User:Dantman/Anti-spam_systemhttps://www.mediawiki.org/wiki/Requests_for_comment/Entrypoint_Routing_and_…https://www.mediawiki.org/wiki/User:Dantman/CodeReviewSystem and
http://gareth-review.com/
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> What are you referring to here? The following definitely does NOT work:
>
> #REDIRECT [[Article title#Section name]]
>
> Timwi
It does, kinda: you need to use an underscore in the Section_name, to
reflect the fact that the ID in question has that underscore (and has done
for the past couple of years).
Harry
--
Harry Burt (User:Jarry1250)