Strategy document?

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Strategy document?

John at Darkstar
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_07))
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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Ting Chen-2
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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Bryan Tong Minh
In reply to this post by John at Darkstar
On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Chad
On Tue, Sep 30, 2008 at 9:58 AM, Bryan Tong Minh
<[hidden email]>wrote:

> On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar <[hidden email]> 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
> [hidden email]
> 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
_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

John at Darkstar

Chad skrev:

> On Tue, Sep 30, 2008 at 9:58 AM, Bryan Tong Minh
> <[hidden email]>wrote:
>
>> On Tue, Sep 30, 2008 at 7:06 AM, John at Darkstar <[hidden email]> 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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Brion Vibber-3
In reply to this post by John at Darkstar
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjlRS4ACgkQwRnhpk1wk44xqACdH5ejN2raP0fIJeoN6mi0I27N
KKoAn1uOodbcmsGuBWdOzj/DRiR4jive
=MQ9d
-----END PGP SIGNATURE-----

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

John at Darkstar
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Gerard Meijssen-3
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 <[hidden email]> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
>
> _______________________________________________
> foundation-l mailing list
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

David Gerard-2
2008/10/3 Gerard Meijssen <[hidden email]>:

> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

John at Darkstar
In reply to this post by Ting Chen-2

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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Birgitte_sb



--- On Fri, 10/3/08, John at Darkstar <[hidden email]> wrote:

> From: John at Darkstar <[hidden email]>
> Subject: Re: [Foundation-l] Strategy document?
> To: "Wikimedia Foundation Mailing List" <[hidden email]>
> 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




     

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Nikola Smolenski
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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Birgitte_sb



--- On Fri, 10/3/08, Nikola Smolenski <[hidden email]> wrote:

> From: Nikola Smolenski <[hidden email]>
> Subject: Re: [Foundation-l] Strategy document?
> To: [hidden email], "Wikimedia Foundation Mailing List" <[hidden email]>
> 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


     

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

geni
In reply to this post by Nikola Smolenski
2008/10/3 Nikola Smolenski <[hidden email]>:
> 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.

--
geni

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

David Gerard-2
2008/10/3 geni <[hidden email]>:
> 2008/10/3 Nikola Smolenski <[hidden email]>:
>> 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?


- d.

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Thomas Dalton
2008/10/3 David Gerard <[hidden email]>:

> 2008/10/3 geni <[hidden email]>:
>> 2008/10/3 Nikola Smolenski <[hidden email]>:
>>> 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?

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

geni
2008/10/3 Thomas Dalton <[hidden email]>:

> 2008/10/3 David Gerard <[hidden email]>:
>> 2008/10/3 geni <[hidden email]>:
>>> 2008/10/3 Nikola Smolenski <[hidden email]>:
>>>> 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.



--
geni

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Aryeh Gregor
In reply to this post by Thomas Dalton
On Fri, Oct 3, 2008 at 10:56 AM, Thomas Dalton <[hidden email]> wrote:

> 2008/10/3 David Gerard <[hidden email]>:
>> 2008/10/3 geni <[hidden email]>:
>>> 2008/10/3 Nikola Smolenski <[hidden email]>:
>>>> 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.

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Gerard Meijssen-3
In reply to this post by David Gerard-2
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 <[hidden email]> wrote:

> 2008/10/3 Gerard Meijssen <[hidden email]>:
>
> > 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Strategy document?

Brion Vibber-3
In reply to this post by John at Darkstar
-----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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
>
> _______________________________________________
> foundation-l mailing list
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjmaXgACgkQwRnhpk1wk45adwCfWKS1DCq6KjFyWfNELZqNhNNi
bhsAoJvyXzi6c9l6Ql9vJM5qg+XPlmQU
=KN4E
-----END PGP SIGNATURE-----

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
123