--- On Fri, 10/3/08, John at Darkstar <vacuum(a)jeb.no> wrote:
From: John at Darkstar <vacuum(a)jeb.no>
Subject: Re: [Foundation-l] Strategy document?
To: "Wikimedia Foundation Mailing List"
<foundation-l(a)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