[Foundation-l] Strategy document?

[John at Darkstar]

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