Is there any strategy document that describes what kind of functionality we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
It seems like there are no such document at mediawiki.org or on meta, yet there are some rather old docs about specific hardware issues. Same on wikimediafoundation.org, there are some references on pages about job openings but thats all.
The closest I could get to such a document is "Update of Foundation organization (March 07)" (http://wikimediafoundation.org/wiki/Update_of_Foundation_organization_(March...)) and the document "10 wishes for 2008" (http://wikimediafoundation.org/wiki/10_wishes_for_2008)
I believe that some kind of document, describing whats important to add to Mediawiki, and why, is very important for the overall community. This would give us an opportunity to clarify why we want to do something and how we would like to do such a thing. It will also make it possible to approach specific benefactors, patrons and donors, especially those that share a common goal with us.
Where should such a document be made, and who should write it? I guess it should clearly state why we want a specific functionality. To make an example, the 2007-document talks about wap functionality; why do we want it and where is it documented in full detail. The page about the functionality should point to all relevant bugs, code and discussions, while the overall document should clearly describe why we want it.
Note that this not a document to block all those that want to write some kind of funny extension, it is a document to describe what we think is important to do.
John
Hello John,
I fully agree with you and indeed I just wanted to make this a topic for the board meeting in January. But I think a discussion, or even a site on meta, where we can discuss and elaborate this, would be very very good. We have developers from community, mainly they make what they think is just important for them. Mostly MediaWiki grew in the past in this way. But now we also have employees, and I think they should work more purposefully and keep their concentration on features that are considered by the community as important.
So, please keep the discussion here and on meta on. That would be great.
Ting
Some of my points, although not exactly strategy - more like desperatly needed features
* better references - why should the writer add metadata for the references, this should be added automatically if possible, probably there should be a central store for this, and probably there should be partners for this
In Norway we have been talking to several newspapers, companies and institutions about how we can do this. We have some ideas, and in general it is to either use Dublin Core, or to synthesize similar data. Identification of the referenced documents are a real problem, as a lot of them has no valid digital identification.
There should also be some solution to the wikicodebloat in the text due to references. A much better mechanism should be used, as the present solution makes the wikicode completly unreadable.
* simpler editing - wikicode has become much to complicated, especially with some of the more advanced templates, it should be possible to use a kind of simplified WYSIWYG editor
Just to be able to write the text in a WYSWYG-manner, and then add templates in special druids would help a lot. There are many peoples that wants to help out with the formatting, but few to actually write the text.
* guidance during writing - new editors have no idea of all the bits and pieces that has to be added and there should be some kind of druid to help in the process
Made an attempt on this the last week. Its functional, well, something works... :]
* map symbols - we need a working map with symbols that is better integrated with commons, that is, addition of new types of map graphics should be a lot simpler, also there should be some kind of mechanism to specify the level where something becomes visible
We also needs a map that is scaleable to a much higher level of details than presently. I think this will be a lot better in a few years.
I think that what we needs here is a real reason that triggers interest in using the maps and geoloc. Perhaps a better navigation model that explores geolocs can do something, for example a listing of articles about nearby areas.
* better statistics - it is necessary to get better statistics, both to be able to say something about how we are used, but also to make decisions about what to use at portals and the main page
I think Eric Zachte could say a lot about this.
* better dynamic lists - Wikinews uses a very old and simplified implementation of dpl, this needs an upgrade whatever that should be, also this kind of functionality should be available in Wikipedia
What do we need, and does DPL solves the problem? Is this good enough for general use? Does it need some kind of limiting mechanism? Should it be reimplemented?
* better portals - it is now a lot of portals that is more or less dead, those needs better solutions and better integration with categories
Is it possible to make better portals? Especially, is it possible to make them such that they don't need any updating? I think they should be lot more dynamic and reflect our good articles, and at the same time reflect what people are reading. Especially on Wikinews. To do this we need better statistics.
A patch for the existing Extension:Intersection is made, but it seems like there are no discussion or interest in doing anything about it.
* automatic updates - a lot of places there are wikicode instead of automatic mechanisms, it seems like there are some idea that wikicode is the goal instead of wikicode to be a tool, and this creates problems as people use to much time on maintaining wikicode
For example, is it possible to make magic words for one project available on other projects? What about common data, how can that be transfered with less manual work? What about common javascript code?
* common javascript store - gadgets are nice but they should be delivered from a central store, not being reimplemented at each project
At no.wp we have a gadget to sort the iw-links, and a few other projects uses it, but each project maintain their own version. This is not very effective. Meta should be the store for such code, but only admins at meta has access to protected pages at meta.
A central store must also solve the problem with localization of javascript code. That means preprocessing the pages before delivery. Imagine something like a namespace on meta called "Gadgets" and a m4-parser or C-preprosessor that transforms the pages into correct code, and a template _() to do localization.
John
--- On Fri, 10/3/08, John at Darkstar vacuum@jeb.no wrote:
From: John at Darkstar vacuum@jeb.no Subject: Re: [Foundation-l] Strategy document? To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Friday, October 3, 2008, 6:12 AM Some of my points, although not exactly strategy - more like desperatly needed features
- better references - why should the writer add metadata
for the references, this should be added automatically if possible, probably there should be a central store for this, and probably there should be partners for this
In Norway we have been talking to several newspapers, companies and institutions about how we can do this. We have some ideas, and in general it is to either use Dublin Core, or to synthesize similar data. Identification of the referenced documents are a real problem, as a lot of them has no valid digital identification.
There should also be some solution to the wikicodebloat in the text due to references. A much better mechanism should be used, as the present solution makes the wikicode completly unreadable.
- simpler editing - wikicode has become much to
complicated, especially with some of the more advanced templates, it should be possible to use a kind of simplified WYSIWYG editor
Just to be able to write the text in a WYSWYG-manner, and then add templates in special druids would help a lot. There are many peoples that wants to help out with the formatting, but few to actually write the text.
- guidance during writing - new editors have no idea of all
the bits and pieces that has to be added and there should be some kind of druid to help in the process
Made an attempt on this the last week. Its functional, well, something works... :]
- map symbols - we need a working map with symbols that is
better integrated with commons, that is, addition of new types of map graphics should be a lot simpler, also there should be some kind of mechanism to specify the level where something becomes visible
We also needs a map that is scaleable to a much higher level of details than presently. I think this will be a lot better in a few years.
I think that what we needs here is a real reason that triggers interest in using the maps and geoloc. Perhaps a better navigation model that explores geolocs can do something, for example a listing of articles about nearby areas.
- better statistics - it is necessary to get better
statistics, both to be able to say something about how we are used, but also to make decisions about what to use at portals and the main page
I think Eric Zachte could say a lot about this.
- better dynamic lists - Wikinews uses a very old and
simplified implementation of dpl, this needs an upgrade whatever that should be, also this kind of functionality should be available in Wikipedia
What do we need, and does DPL solves the problem? Is this good enough for general use? Does it need some kind of limiting mechanism? Should it be reimplemented?
- better portals - it is now a lot of portals that is more
or less dead, those needs better solutions and better integration with categories
Is it possible to make better portals? Especially, is it possible to make them such that they don't need any updating? I think they should be lot more dynamic and reflect our good articles, and at the same time reflect what people are reading. Especially on Wikinews. To do this we need better statistics.
A patch for the existing Extension:Intersection is made, but it seems like there are no discussion or interest in doing anything about it.
- automatic updates - a lot of places there are wikicode
instead of automatic mechanisms, it seems like there are some idea that wikicode is the goal instead of wikicode to be a tool, and this creates problems as people use to much time on maintaining wikicode
For example, is it possible to make magic words for one project available on other projects? What about common data, how can that be transfered with less manual work? What about common javascript code?
- common javascript store - gadgets are nice but they
should be delivered from a central store, not being reimplemented at each project
At no.wp we have a gadget to sort the iw-links, and a few other projects uses it, but each project maintain their own version. This is not very effective. Meta should be the store for such code, but only admins at meta has access to protected pages at meta.
A central store must also solve the problem with localization of javascript code. That means preprocessing the pages before delivery. Imagine something like a namespace on meta called "Gadgets" and a m4-parser or C-preprosessor that transforms the pages into correct code, and a template _() to do localization.
As long as we are creaing a wish list:
Ability to transcribe musical scores in wikitext.
More of a database aspect towards metedata
Abilty to download/print/export all subpages of a page at once.
Abilty to upload complete scans of books to Commons as one file.
Birgitte SB
Birgitte SB wrote:
As long as we are creaing a wish list:
Ability to transcribe musical scores in wikitext.
Easily doable.
More of a database aspect towards metedata
A bit less easily doable.
Abilty to upload complete scans of books to Commons as one file.
Already exists. http://commons.wikimedia.org/wiki/Commons:DjVu
--- On Fri, 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
From: Nikola Smolenski smolensk@eunet.yu Subject: Re: [Foundation-l] Strategy document? To: birgitte_sb@yahoo.com, "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Friday, October 3, 2008, 9:10 AM Birgitte SB wrote:
As long as we are creaing a wish list:
Ability to transcribe musical scores in wikitext.
Easily doable.
Not securely. Or so I hear.
More of a database aspect towards metedata
A bit less easily doable.
Abilty to upload complete scans of books to Commons as
one file.
Already exists. http://commons.wikimedia.org/wiki/Commons:DjVu
Many complete books surpass the upload limit and have to be broken down into smaller files.
Birgitte SB
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote:
As long as we are creaing a wish list:
Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote:
Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
2008/10/3 Thomas Dalton thomas.dalton@gmail.com:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote:
Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
http://meta.wikimedia.org/wiki/Music_markup#Lilypond
That would be from 2005 so things might have changed.
On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote:
Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
The problem is that the solution people have proposed, LilyPond, includes a scripting language. There's a safe mode to disable some of the more unpleasant features, but apparently that's not safe enough: it can still easily be DoS'd by infinite loops. Info on LilyPond's safe mode:
"--safe does not detect resource overuse. It is still possible to make the program hang indefinitely, for example by feeding cyclic data structures into the backend. Therefore, if using LilyPond on a publicly accessible webserver, the process should be limited in both CPU and memory usage." http://lilypond.org/doc/v2.9/Documentation/user/lilypond/Invoking-lilypond
I.e., people are going to write inefficient (even if well-intentioned) Scheme programs into their music that will collectively cause the music rendering servers to run like snails, so people will militate to get more music servers so that trivial music snippets can render in less than two minutes, then people will write even *more* inefficient code, then . . .
Basically, anyone who can execute arbitrary code on Wikimedia servers (even sandboxed) has to be trusted to not just be well-intentioned, but *good at writing efficient code*. And that's not an assumption that can be extended to even a small fraction of sysops, let alone the average user typing stuff into the edit page.
It's already enough of a headache that people write absurdly complicated templates, but that's carefully limited. You'll notice that there are no looping or recursion constructs in wikitext, plus there are length limits on the size of the executed code -- so the run time of any wikitext parsing is bounded, and making sure it's efficient enough is just a matter of tweaking the bounds or the implementation, no matter how lousy the code is that people write. If it's too slow it will just refuse to run, skipping template inclusions and similar.
There is a place in the world for programming languages, and a place for less powerful languages. Arbitrary typesetting is *arguably* a place where real programming languages are needed. But I'm willing to bet that typesetting music specifically is not, in the overwhelming majority of cases, or certainly not for our purposes.
All this is similar to the situation with math markup. LaTeX would be extremely unsafe to run on arbitrary user input, so we only run a very limited subset of it, with allowable codes whitelisted. This uses an extension that basically parses the input and throws an error if it doesn't recognize one of the codes used, and only passes it off to LaTeX if there are no errors.
If someone were to write a similar extension that parsed LilyPond input and ensured that it contained no programming constructs (flow control, loops, functions, . . .) of any kind, it could potentially be enabled, but not if it just passes things on to LilyPond. Similarly, if the LilyPond developers would be willing to create a mode that actually disables all programming constructs and only allows simple-minded stuff like the example at http://meta.wikimedia.org/wiki/Music_markup#Using_Lilypond (I'm assuming that the codes there are simple positional things), then we might be able to use it directly.
But until then, nobody's written any music extension yet that's usable for us. It could certainly be done, and if it's a high priority then Wikimedia could certainly pay someone to do it, but it's not *quite* as trivial as you might think. Although I don't expect it would be terribly difficult either, if someone who understood the requirements put in the time.
On Fri, Oct 3, 2008 at 6:56 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
But until then, nobody's written any music extension yet that's usable for us. It could certainly be done, and if it's a high priority then Wikimedia could certainly pay someone to do it, but it's not *quite* as trivial as you might think. Although I don't expect it would be terribly difficult either, if someone who understood the requirements put in the time.
In anycase somebody cares to write one, don't follow the latex way and write it in a programming language that other people do understand ;)
Bryan
On Friday 03 October 2008 18:56:17 Aryeh Gregor wrote:
On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton thomas.dalton@gmail.com
wrote:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote:
Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
The problem is that the solution people have proposed, LilyPond, includes a scripting language. There's a safe mode to disable some of the more unpleasant features, but apparently that's not safe enough: it can still easily be DoS'd by infinite loops. Info on LilyPond's safe mode:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
--- On Fri, 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
From: Nikola Smolenski smolensk@eunet.yu Subject: Re: [Foundation-l] Strategy document? To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Friday, October 3, 2008, 5:07 PM On Friday 03 October 2008 18:56:17 Aryeh Gregor wrote:
On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton
thomas.dalton@gmail.com wrote:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski
Birgitte SB wrote: > Ability to transcribe musical
scores in wikitext.
Easily doable.
Close. It's been done but with
security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a
dangerous weapon
either... surely it's just putting lots of
pictures together?
The problem is that the solution people have proposed,
LilyPond,
includes a scripting language. There's a safe
mode to disable some of
the more unpleasant features, but apparently
that's not safe enough:
it can still easily be DoS'd by infinite loops.
Info on LilyPond's
safe mode:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
Is there a Mediawiki extension for this notation?
Birgitte SB
On Saturday 04 October 2008 04:35:19 Birgitte SB wrote:
--- On Fri, 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
Is there a Mediawiki extension for this notation?
Now there is: http://testwiki.smolenski.rs/index.php/ABC_Extension
On Sun, Oct 5, 2008 at 10:24 AM, Nikola Smolenski smolensk@eunet.yu wrote:
On Saturday 04 October 2008 04:35:19 Birgitte SB wrote:
--- On Fri, 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
Is there a Mediawiki extension for this notation?
Now there is: http://testwiki.smolenski.rs/index.php/ABC_Extension
I've found the http://www.mediawiki.org/wiki/Extension:AbcMusic . Is the same extension?
Luiz Augusto wrote:
On Sun, Oct 5, 2008 at 10:24 AM, Nikola Smolenski smolensk@eunet.yu wrote:
On Saturday 04 October 2008 04:35:19 Birgitte SB wrote:
--- On Fri, 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
Is there a Mediawiki extension for this notation?
Now there is: http://testwiki.smolenski.rs/index.php/ABC_Extension
I've found the http://www.mediawiki.org/wiki/Extension:AbcMusic . Is the same extension?
No, I didn't knew it exists. AbcMusic converts ABC notation to Lilypond and then renders it (so, it still has some security concerns) while I'm rendering ABC directly.
--- On Mon, 10/6/08, Nikola Smolenski smolensk@eunet.yu wrote:
From: Nikola Smolenski smolensk@eunet.yu Subject: Re: [Foundation-l] Strategy document? To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Monday, October 6, 2008, 1:29 AM Luiz Augusto wrote:
On Sun, Oct 5, 2008 at 10:24 AM, Nikola Smolenski
smolensk@eunet.yu wrote:
On Saturday 04 October 2008 04:35:19 Birgitte SB
wrote:
--- On Fri, 10/3/08, Nikola Smolenski
smolensk@eunet.yu wrote:
There is the other solution, ABC notation.
To my knowledge,
it is fully adequate for our needs, and there are no
security problems.
Is there a Mediawiki extension for this
notation?
Now there is:
http://testwiki.smolenski.rs/index.php/ABC_Extension
I've found the
http://www.mediawiki.org/wiki/Extension:AbcMusic . Is the
same extension?
No, I didn't knew it exists. AbcMusic converts ABC notation to Lilypond and then renders it (so, it still has some security concerns) while I'm rendering ABC directly.
Thank you for working on this. I left a comment on Bug 189 (add wikimusic extention) about the new extention.
Birgitte SB
How do you draw slurs in abc? (Trick question...) Saying abc is a replacement for lilypond is like saying that plain text is a replacement for LaTeX math, strictly correct but with significant compromises.
The right thing to do is to offer a limited subset of the language just as we don't allow SVG+js.
On 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
On Friday 03 October 2008 18:56:17 Aryeh Gregor wrote:
On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton thomas.dalton@gmail.com
wrote:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote: > Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
The problem is that the solution people have proposed, LilyPond, includes a scripting language. There's a safe mode to disable some of the more unpleasant features, but apparently that's not safe enough: it can still easily be DoS'd by infinite loops. Info on LilyPond's safe mode:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Friday 10 October 2008 01:07:28 Gregory Maxwell wrote:
How do you draw slurs in abc? (Trick question...) Saying abc is a replacement for lilypond is like saying that plain text is a replacement for LaTeX math, strictly correct but with significant compromises.
The right thing to do is to offer a limited subset of the language just as we don't allow SVG+js.
However, for years, no one is able to offer that limited subset.
On 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
On Friday 03 October 2008 18:56:17 Aryeh Gregor wrote:
On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton thomas.dalton@gmail.com
wrote:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu: > Birgitte SB wrote: >> Ability to transcribe musical scores in wikitext. > > Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
The problem is that the solution people have proposed, LilyPond, includes a scripting language. There's a safe mode to disable some of the more unpleasant features, but apparently that's not safe enough: it can still easily be DoS'd by infinite loops. Info on LilyPond's safe mode:
There is the other solution, ABC notation. To my knowledge, it is fully adequate for our needs, and there are no security problems.
On Thu, Oct 9, 2008 at 10:07 PM, Nikola Smolenski smolensk@eunet.yu wrote:
On Friday 10 October 2008 01:07:28 Gregory Maxwell wrote:
How do you draw slurs in abc? (Trick question...) Saying abc is a replacement for lilypond is like saying that plain text is a replacement for LaTeX math, strictly correct but with significant compromises.
The right thing to do is to offer a limited subset of the language just as we don't allow SVG+js.
However, for years, no one is able to offer that limited subset.
I don't know that anyone has bothered trying, or at least I know that I haven't. I had been under the impression that the blocker was the general architecture of the WikiTeX stuff which had nothing to do with lilypond. The scheme stuff should be relatively straight forward to disallow.
--- On Fri, 10/10/08, Gregory Maxwell gmaxwell@gmail.com wrote:
From: Gregory Maxwell gmaxwell@gmail.com Subject: Re: [Foundation-l] Strategy document? To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Friday, October 10, 2008, 12:59 AM On Thu, Oct 9, 2008 at 10:07 PM, Nikola Smolenski smolensk@eunet.yu wrote:
On Friday 10 October 2008 01:07:28 Gregory Maxwell
wrote:
How do you draw slurs in abc? (Trick question...)
Saying abc is a
replacement for lilypond is like saying that plain
text is a
replacement for LaTeX math, strictly correct but
with significant
compromises.
The right thing to do is to offer a limited subset
of the language
just as we don't allow SVG+js.
However, for years, no one is able to offer that
limited subset.
I don't know that anyone has bothered trying, or at least I know that I haven't. I had been under the impression that the blocker was the general architecture of the WikiTeX stuff which had nothing to do with lilypond. The scheme stuff should be relatively straight forward to disallow.
Are you saying that you now plan to bother trying?
I am sure that there are tons of cool things that can be done with different kinds of software if only developers would volunteer the time to work on the issues. Nikola is volunteering to work on abc and other developers seem to respond with "but Lilypond is cooler" All I know is Wikisource has been getting requests for music for years. After my prodding, I had been told that it is up to Lilypond to fix their issues before WMF will consider enabling the software. None of our devs seem willing to make Lilypond work. The bug has been open for 4 years. If we have someone volunteering to get abc working for Wikisource, what is the issue? Whatever the defects, it is a great improvement over page scans.
Birgitte SB
Thomas Dalton wrote:
2008/10/3 David Gerard dgerard@gmail.com:
2008/10/3 geni geniice@gmail.com:
2008/10/3 Nikola Smolenski smolensk@eunet.yu:
Birgitte SB wrote:
Ability to transcribe musical scores in wikitext.
Easily doable.
Close. It's been done but with security issues.
o_0 Dare I ask?
I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?
Yes, I initially assumed it was similar to the <math> TeX notation, but apparently its more like a scripting language: https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c37 http://en.wikipedia.org/wiki/GNU_LilyPond
On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar vacuum@jeb.no wrote:
I believe that some kind of document, describing whats important to add to Mediawiki, and why, is very important for the overall community. This would give us an opportunity to clarify why we want to do something and how we would like to do such a thing. It will also make it possible to approach specific benefactors, patrons and donors, especially those that share a common goal with us.
Just as a clarification, things that are important but may seem to be neglected are not neglected because the developers think it is a bad idea, but usually because there is no developer available who has the time for it, especially if it concerns large projects.
Bryan
On Tue, Sep 30, 2008 at 9:58 AM, Bryan Tong Minh bryan.tongminh@gmail.comwrote:
On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar vacuum@jeb.no wrote:
I believe that some kind of document, describing whats important to add to Mediawiki, and why, is very important for the overall community. This would give us an opportunity to clarify why we want to do something and how we would like to do such a thing. It will also make it possible to approach specific benefactors, patrons and donors, especially those that share a common goal with us.
Just as a clarification, things that are important but may seem to be neglected are not neglected because the developers think it is a bad idea, but usually because there is no developer available who has the time for it, especially if it concerns large projects.
Bryan
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Agreed. We've got an excellent team of mostly volunteers who develop MediaWiki. As volunteers, we get a bit of freedom to decide for ourselves what we want to work on. Mostly its things that are interesting or particularly useful.
The hard bugs, especially Parser bugs, get less lovin' because of just that: they're hard. Most volunteer developers would rather work on something that interests them as opposed to a really hard-to-fix edge case for the Parser ;-)
That being said, MediaWiki is currently developed to address the needs of the community first, and I think we do a very good job at that. I know most developers are active on IRC (#mediawiki), and mailing lists (wiktech-l is a great resource). I know several developers keep an eye on the English Wikipedia's Village Pump (technical). There certainly is a lot of communication going back and forth these days, and that's a very good thing to see.
As far as sitting down and formulating a formal roadmap, I can see the benefit. There is [[mw:MediaWiki roadmap]], but it's largely shaped by developers. Perhaps the community could develop its own roadmap and we can keep the MediaWiki.org one a bit more updated with community ideas as well?
The recent influx of developers has brought a lot of talent, and I personally am excited to see where development heads over the next months and years.
-Chad
Chad skrev:
On Tue, Sep 30, 2008 at 9:58 AM, Bryan Tong Minh bryan.tongminh@gmail.comwrote:
On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar vacuum@jeb.no wrote:
I believe that some kind of document, describing whats important to add to Mediawiki, and why, is very important for the overall community. This would give us an opportunity to clarify why we want to do something and how we would like to do such a thing. It will also make it possible to approach specific benefactors, patrons and donors, especially those that share a common goal with us.
Just as a clarification, things that are important but may seem to be neglected are not neglected because the developers think it is a bad idea, but usually because there is no developer available who has the time for it, especially if it concerns large projects.
Agreed. We've got an excellent team of mostly volunteers who develop MediaWiki. As volunteers, we get a bit of freedom to decide for ourselves what we want to work on. Mostly its things that are interesting or particularly useful.
Just to clarify the others clarifications, I think the current codebase is great, and the developers does a great job! But, this is the peoblem, they are developers and thinks about the problems in an other way than writers. Most of the time this works out quite well, but sometimes the solutions are to difficult to use for must writers. A lot of our readers don't know how the system works at all, they have enough problems figuring out how to find the correct article...
I believe a starting point would be to open a discussion about what the writers believe are difficult and the how the developers think those aspects can be simplified.
John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John at Darkstar wrote:
Is there any strategy document that describes what kind of functionality we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
- -- brion
A strategy document is a lot more than technical issues. One thing is how it is implemented, ie. the technical issues or the "how", an other thing is the policy, ie. the "why". The last part probably belongs on this list, while the technical issues must be resolved on the wikitech-l.
I'm not sure if this discussion at all should resolve around technical solutions, I think it is more of a community decision - what functionality does the community (Wikipedia, Wikinews, etc) want and why. Any idea how we can involve the community in this?
John
Brion Vibber skrev:
John at Darkstar wrote:
Is there any strategy document that describes what kind of functionality we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
-- brion
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, If anything I am interested in the "what" question. Once you have an opinion on what you want to change, you should have largely answered the why question. There are several things that I want to see changed or implemented. My "why" is that MediaWiki and Wikipedia are more and more used by people who use other languages then English currently some 50%.
What: Localisation - We have been really fortunate in the work done with Nikerabbit and Siebrand in the lead at Betawiki. A lot of work has been done to make Betawiki a great environment for the localisation of software, specifically for MediaWiki. One recent new promissing part of the project is the creation of articles that can be translated in multiple languages and, it even has a first iteration of some management functionality to maintain the translations.
Commons - As I wrote as long ago as 2005, it should be possible to tag all the media at Commons with labels that show up in the language selected in the user preferences. This has two benefits; it becomes easier for Wikimedians to find pictures to illustrate articles and second it becomes easier for people to find freely licensed material to enrich their work. I have been working on a proof of concept and it is clear that we can actually do this.
So for these funtionalities the what and the why are clear, the how has more then a clear outline and the question is how to move forward.
Thanks, GerardM
On Fri, Oct 3, 2008 at 9:25 AM, John at Darkstar vacuum@jeb.no wrote:
A strategy document is a lot more than technical issues. One thing is how it is implemented, ie. the technical issues or the "how", an other thing is the policy, ie. the "why". The last part probably belongs on this list, while the technical issues must be resolved on the wikitech-l.
I'm not sure if this discussion at all should resolve around technical solutions, I think it is more of a community decision - what functionality does the community (Wikipedia, Wikinews, etc) want and why. Any idea how we can involve the community in this?
John
Brion Vibber skrev:
John at Darkstar wrote:
Is there any strategy document that describes what kind of functionality we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
-- brion
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
2008/10/3 Gerard Meijssen gerard.meijssen@gmail.com:
Commons - As I wrote as long ago as 2005, it should be possible to tag all the media at Commons with labels that show up in the language selected in the user preferences. This has two benefits; it becomes easier for Wikimedians to find pictures to illustrate articles and second it becomes easier for people to find freely licensed material to enrich their work. I have been working on a proof of concept and it is clear that we can actually do this.
This has been on the "desperately wanted" list for Commons for a while:
* categories that behave like tags (so complex Boolean queries can be run quickly) * cats/tags that have multiple names (so "Category:Dogs" and "Category:Chiens" are the same thing)
I understand work is in progress on both of these, though there's no estimate on time of arrival.
- d.
Hoi, The proof of concept project, warts and all, is at http://commons.i-iter.org/index.php/Category:Felis_silvestris_catus . It is true alpha software :) it does do its trick..
It does need some more pretifying and tlc..
Thanks, GerardM
On Fri, Oct 3, 2008 at 11:31 AM, David Gerard dgerard@gmail.com wrote:
2008/10/3 Gerard Meijssen gerard.meijssen@gmail.com:
Commons - As I wrote as long ago as 2005, it should be possible to tag
all
the media at Commons with labels that show up in the language selected in the user preferences. This has two benefits; it becomes easier for Wikimedians to find pictures to illustrate articles and second it becomes easier for people to find freely licensed material to enrich their work.
I
have been working on a proof of concept and it is clear that we can
actually
do this.
This has been on the "desperately wanted" list for Commons for a while:
- categories that behave like tags (so complex Boolean queries can be
run quickly)
- cats/tags that have multiple names (so "Category:Dogs" and
"Category:Chiens" are the same thing)
I understand work is in progress on both of these, though there's no estimate on time of arrival.
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John at Darkstar wrote:
A strategy document is a lot more than technical issues. One thing is how it is implemented, ie. the technical issues or the "how", an other thing is the policy, ie. the "why". The last part probably belongs on this list, while the technical issues must be resolved on the wikitech-l.
I'm not sure if this discussion at all should resolve around technical solutions, I think it is more of a community decision - what functionality does the community (Wikipedia, Wikinews, etc) want and why.
Fair enough, but don't forget you need community buy-in on the tech side as well. :)
As some general background:
For this year, a lot of the core work the tech team is putting in is on infrastructure, both technical and human:
* Identifying weak spots in system administration, physical setup, monitoring, backups, failover -- and fixing them.
* Identifying weak spots in community management -- handling of bug reports, patch review, site problem reports, site requests -- and smoothing them out.
As we're improving these things, we'll also start ramping up more focused activity on user-oriented software development, which is probably what you guys are more interested in. :)
A few targets on my top list include:
== Usability improvements ==
This is a big category. :) In many ways, pretty much everything is going to fall under usability somehow!
We're hoping to get some funding to help on both small and large usability projects over the next year; we want to see a mix of staff, contract, and volunteer developers all doing lots of awesome things.
Some of the major things I'm interested in...
== Humane article approval and deletion processes ==
At least on English Wikipedia, there are some major cultural problems.
The manual systems for things like article deletion today are just plain *nasty*. Newbie comes and adds something, it gets deleted, maybe they get insulted, maybe they can't figure out why or what happened, they can't find where their old text went, general fighting ensues.
These sorts of systems need to be discoverable and humane. If my article's being deleted, I should: a) Clearly understand it was provisional to begin with b) Find out how it got marked as not-to-be-kept c) Understand how and where to address it d) Be able to recover my stuff easily to take it elsewhere or make it available for someone else to improve later.
Technology doesn't solve everything, but dedicated support for communication channels, in combination with community interest in people treating each other like human beings, could help a lot.
== Non-horrible discussion interfaces ==
LiquidThreads is still being worked on; whether we ultimately adopt it or if someone restarts in a different way, large discussion areas like the Village Pumps especially can benefit a lot from a discussion/forum interface that can be managed, searched, responded to easily.
== Saner vandalism watching ==
More integrated and adaptive flagging and filtering can help to concentrate human eyes on where they're needed. Particularly disruptive actions, such as traditional page move vandalism, can be better addressed with some additional "self-moderation aids" such as pre-queueing and emergency shutoff buttons, without the need to block everyone or play games with "you can vandalise all you want after X arbitrary condition is passed".
This is all about reducing blood pressure and freeing up eyes and brains to do something more fun. :)
== Saner edit interfaces ==
There are a lot of areas that can be addressed here, such as:
* Integrated visual editing tools for selection and use of templates, tables, references, categories, etc * A general editor that hides some of the complexity of those extra data references when you're mainly interested in paragraph text -- extraction and on-demand expansion of templates, tables, references in the editor. (Maybe a touch of syntax highlighting, but not too scary. :)
Bits and pieces will probably come in over time. We don't expect to "go WYSIWYG" any time soon, but HTML editor widgets can serve as a useful base technology for helpful things (like the syntax highlighting in WikEd).
== Queriable metadata ==
Even if we don't end up taking on the full Semantic MediaWiki system, there can be huge benefit to being able to grab fields out of templates.
== Media uploads ==
Media upload sanity -- currently this whole thing's a mess. Lots of things to address!
* Easier selection of existing media to add inline before you decide to upload! * Allow uploading from the editor without disturbing your work (or losing your edit) * Better integration with Commons from the project sites * A sane way of getting license information * A sane way of storing and exposing license information that's machine-readable * Correct handling of photos rotated in-camera * Assists and transcoding for audio, video media * Transparent support for more image file formats, including ability to link source and output files * Online image manipulation -- ability to created cropped or labeled versions of images without muss or fuss
== Native geodata support ==
Store data from geographic coordinate templates, provide a standard API for doing location-based searches. This will be a particular aid to handheld/mobile tools, another of my hobby horses :) but also to in-wiki interactive maps, which would be awesome.
== Not losing data ==
Things like saving edit drafts so users don't lose their hard work if a submit fails dramatically or their browser crashes -- or they just navigate away, close the browser by mistake, accidentally delete too much...
The little things matter too. :)
Any idea how we can involve the community in this?
Aye, there's the rub -- first how to define community, second how to discuss with them all at once, and third how to deal with the mountain of idea requests. :)
- -- brion
John
Brion Vibber skrev:
John at Darkstar wrote:
Is there any strategy document that describes what kind of functionality we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
-- brion
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Somehow I believe we have enough developers (!) but we have a lack of community support of them. ;)
You have a lot of good points, especially on the deletion process. It work from our side, but probably not from the newbie's side.
I think good ideas somehow isn't enough because the community somehow stick to the ideas they know. How to initiate an open discussion, well I don't know. Perhaps some discussion pages, but not on a technical place, the users we want input from are to easily scared away. People without a technical background won't discuss technical issues, and developers has difficulty to address other about technical matters. Not to mention hmi isn't a developers strongest capability, the interactions tend to be to complex because "it's easy!"
Of the things you mention I think the deletion process is the single most important thing because I suspects we are loosing contributors because of this. It has both to do with the deletion process and the lack of possibility to test how things work. Turned around I believe that a users contribution should go to a temp area until he finishes, and then he should still have a link to his contribution if it is refused.
JOhn
Brion Vibber skrev:
John at Darkstar wrote:
A strategy document is a lot more than technical issues. One thing is how it is implemented, ie. the technical issues or the "how", an other thing is the policy, ie. the "why". The last part probably belongs on this list, while the technical issues must be resolved on the wikitech-l.
I'm not sure if this discussion at all should resolve around technical solutions, I think it is more of a community decision - what functionality does the community (Wikipedia, Wikinews, etc) want and why.
Fair enough, but don't forget you need community buy-in on the tech side as well. :)
As some general background:
For this year, a lot of the core work the tech team is putting in is on infrastructure, both technical and human:
- Identifying weak spots in system administration, physical setup,
monitoring, backups, failover -- and fixing them.
- Identifying weak spots in community management -- handling of bug
reports, patch review, site problem reports, site requests -- and smoothing them out.
As we're improving these things, we'll also start ramping up more focused activity on user-oriented software development, which is probably what you guys are more interested in. :)
A few targets on my top list include:
== Usability improvements ==
This is a big category. :) In many ways, pretty much everything is going to fall under usability somehow!
We're hoping to get some funding to help on both small and large usability projects over the next year; we want to see a mix of staff, contract, and volunteer developers all doing lots of awesome things.
Some of the major things I'm interested in...
== Humane article approval and deletion processes ==
At least on English Wikipedia, there are some major cultural problems.
The manual systems for things like article deletion today are just plain *nasty*. Newbie comes and adds something, it gets deleted, maybe they get insulted, maybe they can't figure out why or what happened, they can't find where their old text went, general fighting ensues.
These sorts of systems need to be discoverable and humane. If my article's being deleted, I should: a) Clearly understand it was provisional to begin with b) Find out how it got marked as not-to-be-kept c) Understand how and where to address it d) Be able to recover my stuff easily to take it elsewhere or make it available for someone else to improve later.
Technology doesn't solve everything, but dedicated support for communication channels, in combination with community interest in people treating each other like human beings, could help a lot.
== Non-horrible discussion interfaces ==
LiquidThreads is still being worked on; whether we ultimately adopt it or if someone restarts in a different way, large discussion areas like the Village Pumps especially can benefit a lot from a discussion/forum interface that can be managed, searched, responded to easily.
== Saner vandalism watching ==
More integrated and adaptive flagging and filtering can help to concentrate human eyes on where they're needed. Particularly disruptive actions, such as traditional page move vandalism, can be better addressed with some additional "self-moderation aids" such as pre-queueing and emergency shutoff buttons, without the need to block everyone or play games with "you can vandalise all you want after X arbitrary condition is passed".
This is all about reducing blood pressure and freeing up eyes and brains to do something more fun. :)
== Saner edit interfaces ==
There are a lot of areas that can be addressed here, such as:
- Integrated visual editing tools for selection and use of templates,
tables, references, categories, etc
- A general editor that hides some of the complexity of those extra data
references when you're mainly interested in paragraph text -- extraction and on-demand expansion of templates, tables, references in the editor. (Maybe a touch of syntax highlighting, but not too scary. :)
Bits and pieces will probably come in over time. We don't expect to "go WYSIWYG" any time soon, but HTML editor widgets can serve as a useful base technology for helpful things (like the syntax highlighting in WikEd).
== Queriable metadata ==
Even if we don't end up taking on the full Semantic MediaWiki system, there can be huge benefit to being able to grab fields out of templates.
== Media uploads ==
Media upload sanity -- currently this whole thing's a mess. Lots of things to address!
- Easier selection of existing media to add inline before you decide to
upload!
- Allow uploading from the editor without disturbing your work (or
losing your edit)
- Better integration with Commons from the project sites
- A sane way of getting license information
- A sane way of storing and exposing license information that's
machine-readable
- Correct handling of photos rotated in-camera
- Assists and transcoding for audio, video media
- Transparent support for more image file formats, including ability to
link source and output files
- Online image manipulation -- ability to created cropped or labeled
versions of images without muss or fuss
== Native geodata support ==
Store data from geographic coordinate templates, provide a standard API for doing location-based searches. This will be a particular aid to handheld/mobile tools, another of my hobby horses :) but also to in-wiki interactive maps, which would be awesome.
== Not losing data ==
Things like saving edit drafts so users don't lose their hard work if a submit fails dramatically or their browser crashes -- or they just navigate away, close the browser by mistake, accidentally delete too much...
The little things matter too. :)
Any idea how we can involve the community in this?
Aye, there's the rub -- first how to define community, second how to discuss with them all at once, and third how to deal with the mountain of idea requests. :)
-- brion
John
Brion Vibber skrev:
John at Darkstar wrote:
Is there any strategy document that describes what kind of functionality we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
-- brion
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, The deletion process is interesting... it is not working on "our side" and certainly not from a newbie's side. Now the question is not if it is wrong, or why you want to change it but WHAT are you going to change and HOW will this affect the observable issues in a positive way (the issue is to prevent the large amount of false negatives). From any perspective, there is nothing strategic if all you have is a realisation that something is wrong...
So PLEASE do not say what is wrong, Discuss how you want
On Fri, Oct 3, 2008 at 9:23 PM, John at Darkstar vacuum@jeb.no wrote:
Somehow I believe we have enough developers (!) but we have a lack of community support of them. ;)
You have a lot of good points, especially on the deletion process. It work from our side, but probably not from the newbie's side.
I think good ideas somehow isn't enough because the community somehow stick to the ideas they know. How to initiate an open discussion, well I don't know. Perhaps some discussion pages, but not on a technical place, the users we want input from are to easily scared away. People without a technical background won't discuss technical issues, and developers has difficulty to address other about technical matters. Not to mention hmi isn't a developers strongest capability, the interactions tend to be to complex because "it's easy!"
Of the things you mention I think the deletion process is the single most important thing because I suspects we are loosing contributors because of this. It has both to do with the deletion process and the lack of possibility to test how things work. Turned around I believe that a users contribution should go to a temp area until he finishes, and then he should still have a link to his contribution if it is refused.
JOhn
Brion Vibber skrev:
John at Darkstar wrote:
A strategy document is a lot more than technical issues. One thing is how it is implemented, ie. the technical issues or the "how", an other thing is the policy, ie. the "why". The last part probably belongs on this list, while the technical issues must be resolved on the
wikitech-l.
I'm not sure if this discussion at all should resolve around technical solutions, I think it is more of a community decision - what functionality does the community (Wikipedia, Wikinews, etc) want and why.
Fair enough, but don't forget you need community buy-in on the tech side as well. :)
As some general background:
For this year, a lot of the core work the tech team is putting in is on infrastructure, both technical and human:
- Identifying weak spots in system administration, physical setup,
monitoring, backups, failover -- and fixing them.
- Identifying weak spots in community management -- handling of bug
reports, patch review, site problem reports, site requests -- and smoothing them out.
As we're improving these things, we'll also start ramping up more focused activity on user-oriented software development, which is probably what you guys are more interested in. :)
A few targets on my top list include:
== Usability improvements ==
This is a big category. :) In many ways, pretty much everything is going to fall under usability somehow!
We're hoping to get some funding to help on both small and large usability projects over the next year; we want to see a mix of staff, contract, and volunteer developers all doing lots of awesome things.
Some of the major things I'm interested in...
== Humane article approval and deletion processes ==
At least on English Wikipedia, there are some major cultural problems.
The manual systems for things like article deletion today are just plain *nasty*. Newbie comes and adds something, it gets deleted, maybe they get insulted, maybe they can't figure out why or what happened, they can't find where their old text went, general fighting ensues.
These sorts of systems need to be discoverable and humane. If my article's being deleted, I should: a) Clearly understand it was provisional to begin with b) Find out how it got marked as not-to-be-kept c) Understand how and where to address it d) Be able to recover my stuff easily to take it elsewhere or make it available for someone else to improve later.
Technology doesn't solve everything, but dedicated support for communication channels, in combination with community interest in people treating each other like human beings, could help a lot.
== Non-horrible discussion interfaces ==
LiquidThreads is still being worked on; whether we ultimately adopt it or if someone restarts in a different way, large discussion areas like the Village Pumps especially can benefit a lot from a discussion/forum interface that can be managed, searched, responded to easily.
== Saner vandalism watching ==
More integrated and adaptive flagging and filtering can help to concentrate human eyes on where they're needed. Particularly disruptive actions, such as traditional page move vandalism, can be better addressed with some additional "self-moderation aids" such as pre-queueing and emergency shutoff buttons, without the need to block everyone or play games with "you can vandalise all you want after X arbitrary condition is passed".
This is all about reducing blood pressure and freeing up eyes and brains to do something more fun. :)
== Saner edit interfaces ==
There are a lot of areas that can be addressed here, such as:
- Integrated visual editing tools for selection and use of templates,
tables, references, categories, etc
- A general editor that hides some of the complexity of those extra data
references when you're mainly interested in paragraph text -- extraction and on-demand expansion of templates, tables, references in the editor. (Maybe a touch of syntax highlighting, but not too scary. :)
Bits and pieces will probably come in over time. We don't expect to "go WYSIWYG" any time soon, but HTML editor widgets can serve as a useful base technology for helpful things (like the syntax highlighting in
WikEd).
== Queriable metadata ==
Even if we don't end up taking on the full Semantic MediaWiki system, there can be huge benefit to being able to grab fields out of templates.
== Media uploads ==
Media upload sanity -- currently this whole thing's a mess. Lots of things to address!
- Easier selection of existing media to add inline before you decide to
upload!
- Allow uploading from the editor without disturbing your work (or
losing your edit)
- Better integration with Commons from the project sites
- A sane way of getting license information
- A sane way of storing and exposing license information that's
machine-readable
- Correct handling of photos rotated in-camera
- Assists and transcoding for audio, video media
- Transparent support for more image file formats, including ability to
link source and output files
- Online image manipulation -- ability to created cropped or labeled
versions of images without muss or fuss
== Native geodata support ==
Store data from geographic coordinate templates, provide a standard API for doing location-based searches. This will be a particular aid to handheld/mobile tools, another of my hobby horses :) but also to in-wiki interactive maps, which would be awesome.
== Not losing data ==
Things like saving edit drafts so users don't lose their hard work if a submit fails dramatically or their browser crashes -- or they just navigate away, close the browser by mistake, accidentally delete too
much...
The little things matter too. :)
Any idea how we can involve the community in this?
Aye, there's the rub -- first how to define community, second how to discuss with them all at once, and third how to deal with the mountain of idea requests. :)
-- brion
John
Brion Vibber skrev:
John at Darkstar wrote:
Is there any strategy document that describes what kind of
functionality
we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
-- brion
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
2008/10/3 Gerard Meijssen gerard.meijssen@gmail.com:
Hoi, The deletion process is interesting... it is not working on "our side" and certainly not from a newbie's side.
It works great. It turns even our most unstable admins into a faceless bureaucracy.
On Fri, Oct 3, 2008 at 4:04 PM, geni geniice@gmail.com wrote:
2008/10/3 Gerard Meijssen gerard.meijssen@gmail.com:
Hoi, The deletion process is interesting... it is not working on "our side"
and
certainly not from a newbie's side.
It works great. It turns even our most unstable admins into a faceless bureaucracy.
-- geni
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
"Bureaucracy expands to meet the needs of the expanding bureaucracy."
-Chad
http://en.wikiquote.org/wiki/Politics#Government_bureaucracy
Hoi, The deletion process is interesting... it is not working on "our side" and certainly not from a newbie's side. Now the question is not if it is wrong, or why you want to change it but WHAT are you going to change and HOW will this affect the observable issues in a positive way (the issue is to prevent the large amount of false negatives). From any perspective, there is nothing strategic if all you have is a realisation that something is wrong...
So PLEASE do not only say what is wrong, Discuss how you think an issue can be solved. What needs doing... Many issues do not need a technical solution and really we do not have enough developers. (What gives you that idea ???)
What I am missing in much of the discussion is how we are going to make our community more of a community.. This is a recurring theme. It is true, we have some 700 odd communities in loads of languages. At this moment only those that speak English have a fighting chance to be heard. All the others are not heard at all because how can you hear and understand them as well?
Within one of our communities we have them and us. We have admins villifying other admins, and or users. We have people deleting articles that became recognised for their quality. What makes the processes that are involved so noxious ?
There are an increasing amount of studies done on the Wikipedia phenomena. There are research mailing lists, research wikis... The way I see it, there is hardly any strategic use comming out of it because we have not asked our questions to the researchers... I want to know for instance what the effect is of the quality of localisation on both our editors and readers. I want to know how much use Commons is for the projects that use other scripts. What are your questions ?
Thanks, GerardM
On Fri, Oct 3, 2008 at 9:23 PM, John at Darkstar vacuum@jeb.no wrote:
Somehow I believe we have enough developers (!) but we have a lack of community support of them. ;)
You have a lot of good points, especially on the deletion process. It work from our side, but probably not from the newbie's side.
I think good ideas somehow isn't enough because the community somehow stick to the ideas they know. How to initiate an open discussion, well I don't know. Perhaps some discussion pages, but not on a technical place, the users we want input from are to easily scared away. People without a technical background won't discuss technical issues, and developers has difficulty to address other about technical matters. Not to mention hmi isn't a developers strongest capability, the interactions tend to be to complex because "it's easy!"
Of the things you mention I think the deletion process is the single most important thing because I suspects we are loosing contributors because of this. It has both to do with the deletion process and the lack of possibility to test how things work. Turned around I believe that a users contribution should go to a temp area until he finishes, and then he should still have a link to his contribution if it is refused.
JOhn
Brion Vibber skrev:
John at Darkstar wrote:
A strategy document is a lot more than technical issues. One thing is how it is implemented, ie. the technical issues or the "how", an other thing is the policy, ie. the "why". The last part probably belongs on this list, while the technical issues must be resolved on the
wikitech-l.
I'm not sure if this discussion at all should resolve around technical solutions, I think it is more of a community decision - what functionality does the community (Wikipedia, Wikinews, etc) want and why.
Fair enough, but don't forget you need community buy-in on the tech side as well. :)
As some general background:
For this year, a lot of the core work the tech team is putting in is on infrastructure, both technical and human:
- Identifying weak spots in system administration, physical setup,
monitoring, backups, failover -- and fixing them.
- Identifying weak spots in community management -- handling of bug
reports, patch review, site problem reports, site requests -- and smoothing them out.
As we're improving these things, we'll also start ramping up more focused activity on user-oriented software development, which is probably what you guys are more interested in. :)
A few targets on my top list include:
== Usability improvements ==
This is a big category. :) In many ways, pretty much everything is going to fall under usability somehow!
We're hoping to get some funding to help on both small and large usability projects over the next year; we want to see a mix of staff, contract, and volunteer developers all doing lots of awesome things.
Some of the major things I'm interested in...
== Humane article approval and deletion processes ==
At least on English Wikipedia, there are some major cultural problems.
The manual systems for things like article deletion today are just plain *nasty*. Newbie comes and adds something, it gets deleted, maybe they get insulted, maybe they can't figure out why or what happened, they can't find where their old text went, general fighting ensues.
These sorts of systems need to be discoverable and humane. If my article's being deleted, I should: a) Clearly understand it was provisional to begin with b) Find out how it got marked as not-to-be-kept c) Understand how and where to address it d) Be able to recover my stuff easily to take it elsewhere or make it available for someone else to improve later.
Technology doesn't solve everything, but dedicated support for communication channels, in combination with community interest in people treating each other like human beings, could help a lot.
== Non-horrible discussion interfaces ==
LiquidThreads is still being worked on; whether we ultimately adopt it or if someone restarts in a different way, large discussion areas like the Village Pumps especially can benefit a lot from a discussion/forum interface that can be managed, searched, responded to easily.
== Saner vandalism watching ==
More integrated and adaptive flagging and filtering can help to concentrate human eyes on where they're needed. Particularly disruptive actions, such as traditional page move vandalism, can be better addressed with some additional "self-moderation aids" such as pre-queueing and emergency shutoff buttons, without the need to block everyone or play games with "you can vandalise all you want after X arbitrary condition is passed".
This is all about reducing blood pressure and freeing up eyes and brains to do something more fun. :)
== Saner edit interfaces ==
There are a lot of areas that can be addressed here, such as:
- Integrated visual editing tools for selection and use of templates,
tables, references, categories, etc
- A general editor that hides some of the complexity of those extra data
references when you're mainly interested in paragraph text -- extraction and on-demand expansion of templates, tables, references in the editor. (Maybe a touch of syntax highlighting, but not too scary. :)
Bits and pieces will probably come in over time. We don't expect to "go WYSIWYG" any time soon, but HTML editor widgets can serve as a useful base technology for helpful things (like the syntax highlighting in
WikEd).
== Queriable metadata ==
Even if we don't end up taking on the full Semantic MediaWiki system, there can be huge benefit to being able to grab fields out of templates.
== Media uploads ==
Media upload sanity -- currently this whole thing's a mess. Lots of things to address!
- Easier selection of existing media to add inline before you decide to
upload!
- Allow uploading from the editor without disturbing your work (or
losing your edit)
- Better integration with Commons from the project sites
- A sane way of getting license information
- A sane way of storing and exposing license information that's
machine-readable
- Correct handling of photos rotated in-camera
- Assists and transcoding for audio, video media
- Transparent support for more image file formats, including ability to
link source and output files
- Online image manipulation -- ability to created cropped or labeled
versions of images without muss or fuss
== Native geodata support ==
Store data from geographic coordinate templates, provide a standard API for doing location-based searches. This will be a particular aid to handheld/mobile tools, another of my hobby horses :) but also to in-wiki interactive maps, which would be awesome.
== Not losing data ==
Things like saving edit drafts so users don't lose their hard work if a submit fails dramatically or their browser crashes -- or they just navigate away, close the browser by mistake, accidentally delete too
much...
The little things matter too. :)
Any idea how we can involve the community in this?
Aye, there's the rub -- first how to define community, second how to discuss with them all at once, and third how to deal with the mountain of idea requests. :)
-- brion
John
Brion Vibber skrev:
John at Darkstar wrote:
Is there any strategy document that describes what kind of
functionality
we want in Mediawiki, and why we want it? For the moment it seems like the development are drifting in some general direction but without any real specific goal.
Perhaps you want to be asking this in wikitech-l where it might be seen by the people who create MediaWiki? :)
-- brion
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Friday 03 October 2008 20:50:32 Brion Vibber wrote:
John at Darkstar wrote:
Any idea how we can involve the community in this?
Aye, there's the rub -- first how to define community, second how to discuss with them all at once, and third how to deal with the mountain of idea requests. :)
There is one document that would be very useful if it would exist.
Suppose that I would like a feature added to MediaWiki and activated on Wikimedia projects. It could be a feature coded by me, or something that I just imagine and would like someone else to make. What is the procedure for doing it?
On Fri, Oct 3, 2008 at 6:05 PM, Nikola Smolenski smolensk@eunet.yu wrote:
There is one document that would be very useful if it would exist.
Suppose that I would like a feature added to MediaWiki and activated on Wikimedia projects. It could be a feature coded by me, or something that I just imagine and would like someone else to make. What is the procedure for doing it?
1) File a bug at bugzilla.wikimedia.org.
2) Harass everyone you can dig up who might be able to help you with it. Annoy them just enough that they're constantly reminded of it and are impressed with your persistence, but not enough that they put you on their ignore lists.
3) Hope someone pays attention someday.
On Saturday 04 October 2008 00:06:53 Aryeh Gregor wrote:
On Fri, Oct 3, 2008 at 6:05 PM, Nikola Smolenski smolensk@eunet.yu wrote:
There is one document that would be very useful if it would exist.
Suppose that I would like a feature added to MediaWiki and activated on Wikimedia projects. It could be a feature coded by me, or something that I just imagine and would like someone else to make. What is the procedure for doing it?
File a bug at bugzilla.wikimedia.org.
Harass everyone you can dig up who might be able to help you with
it. Annoy them just enough that they're constantly reminded of it and are impressed with your persistence, but not enough that they put you on their ignore lists.
- Hope someone pays attention someday.
I'm pretty sure community approval has to be there somewhere.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nikola Smolenski wrote:
On Saturday 04 October 2008 00:06:53 Aryeh Gregor wrote:
File a bug at bugzilla.wikimedia.org.
Harass everyone you can dig up who might be able to help you with
it. Annoy them just enough that they're constantly reminded of it and are impressed with your persistence, but not enough that they put you on their ignore lists.
- Hope someone pays attention someday.
I'm pretty sure community approval has to be there somewhere.
We try at least. :)
I'd definitely like us to be a little more pro-active at engaging the community with information about things that are being worked on and things that are being planned.
For "big" projects, especially controversial things like Flagged Revisions, that itself can take a long time, trying to work out how policies should be worked out -- what aspects of the software need to reflect policy, and what aspects of policy need to reflect new capabilities (and limitations) of the system.
- -- brion
If limited to proposed technical fixes for known problems, for example in Wikipedia, where should such documents be stored? Note that this is not about Mediawiki as such, its mostly about observed problems in the use and implementation of the software in specific Wikimedia projects.
It seems to me like the documents contain three parts; a problem description (what), a resolution (why) and proposed solutions (how). It must be simple to link to both the mailing archives, to svn, to the mediawiki site, to bugzilla, to the projects, etc. Basically a wiki, and it seems to me like this is something for Meta, but could go on the Mediawiki site too.
The technical discussions could be on Bugzilla, but there should be a statement about important threads under the section for proposed solutions. This makes it more simple to find the discussions. I believe Bugzilla is to alien for most wikipedians, even if it is a good tool for the developers.
I made an example at Meta (http://meta.wikimedia.org/wiki/User:Jeblad/demo)
John
For "big" projects, especially controversial things like Flagged Revisions, that itself can take a long time, trying to work out how policies should be worked out -- what aspects of the software need to reflect policy, and what aspects of policy need to reflect new capabilities (and limitations) of the system.
- -- brion
Sorry, I am lost at this point. I though Flagged Revisions is a business of each project: for instance, we have them in ru.wp, and it took a long time to introduce the flagged revisions, including a broad discussion inside the project. But I do not believe it is a matter of general discussion for instance on meta with the implication that all projects adopt them. AFAIK our ruled and rules on de.wp for flagged revisions are very much different. Is this what you mean?
Cheers Yaroslav
--- On Fri, 10/3/08, Nikola Smolenski smolensk@eunet.yu wrote:
From: Nikola Smolenski smolensk@eunet.yu Subject: Re: [Foundation-l] Strategy document? To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Friday, October 3, 2008, 6:12 PM On Saturday 04 October 2008 00:06:53 Aryeh Gregor wrote:
On Fri, Oct 3, 2008 at 6:05 PM, Nikola Smolenski
smolensk@eunet.yu wrote:
There is one document that would be very useful
if it would exist.
Suppose that I would like a feature added to
MediaWiki and activated on
Wikimedia projects. It could be a feature coded
by me, or something that
I just imagine and would like someone else to
make. What is the procedure
for doing it?
File a bug at bugzilla.wikimedia.org.
Harass everyone you can dig up who might be able to
help you with
it. Annoy them just enough that they're
constantly reminded of it and
are impressed with your persistence, but not enough
that they put you
on their ignore lists.
- Hope someone pays attention someday.
I'm pretty sure community approval has to be there somewhere.
On Fri, Oct 3, 2008 at 7:12 PM, Nikola Smolenski smolensk@eunet.yu wrote:
I'm pretty sure community approval has to be there somewhere.
The overwhelming majority of software changes do not require community approval. Even major new features (e.g., rev_deleted) usually are straightforward improvements that no one is going to object to. Of course, there are occasional exceptions (e.g., FlaggedRevs), but they're rare.
Hoi, There is no such policy. When your feature and the reasons why for this extensions is convincing, you may be in luck. You have to convince ... but first you have to be make yourself heard.
Obviously you can write an entry in Bugzilla ... but this does not make much of a difference, in reality it is about convincing, marketing your idea, your dream. Thanks. GerardM
On Sat, Oct 4, 2008 at 12:05 AM, Nikola Smolenski smolensk@eunet.yu wrote:
On Friday 03 October 2008 20:50:32 Brion Vibber wrote:
John at Darkstar wrote:
Any idea how we can involve the community in this?
Aye, there's the rub -- first how to define community, second how to discuss with them all at once, and third how to deal with the mountain of idea requests. :)
There is one document that would be very useful if it would exist.
Suppose that I would like a feature added to MediaWiki and activated on Wikimedia projects. It could be a feature coded by me, or something that I just imagine and would like someone else to make. What is the procedure for doing it?
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
wikimedia-l@lists.wikimedia.org