[Foundation-l] Strategy document?

[Birgitte SB]

--- On Fri, 10/3/08, John at Darkstar <vacuum at jeb.no> wrote:

> From: John at Darkstar <vacuum at jeb.no>
> Subject: Re: [Foundation-l] Strategy document?
> To: "Wikimedia Foundation Mailing List" <foundation-l at 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