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 upload complete scans of books to Commons as one file.

Birgitte SB wrote: Easily doable.

2008/10/3 geni <geniice(a)gmail.com>om>: o_0 Dare I ask?

2008/10/3 David Gerard <dgerard(a)gmail.com>om>: I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?

On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton <thomas.dalton(a)gmail.com>

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:

--- On Fri, 10/3/08, Nikola Smolenski <smolensk(a)eunet.yu> wrote: Is there a Mediawiki extension for this notation?

On Sun, Oct 5, 2008 at 10:24 AM, Nikola Smolenski <smolensk(a)eunet.yu> wrote: I've found the http://www.mediawiki.org/wiki/Extension:AbcMusic . Is the same extension?

On Friday 03 October 2008 18:56:17 Aryeh Gregor wrote: wrote: 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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Friday 10 October 2008 01:07:28 Gregory Maxwell wrote: However, for years, no one is able to offer that limited subset.

2008/10/3 David Gerard <dgerard(a)gmail.com>om>: I wasn't aware that music could be used as a dangerous weapon either... surely it's just putting lots of pictures together?

On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar <vacuum(a)jeb.no> wrote: 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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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: _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

2008/10/3 Gerard Meijssen <gerard.meijssen(a)gmail.com>om>: all I actually 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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

John at Darkstar wrote: 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. :) 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

Hoi, The deletion process is interesting... it is not working on "our side" and certainly not from a newbie's side.

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: wikitech-l. WikEd). much... functionality _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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 Saturday 04 October 2008 00:06:53 Aryeh Gregor wrote: I'm pretty sure community approval has to be there somewhere.

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

I'm pretty sure community approval has to be there somewhere.