[Foundation-l] Strategy document?

[Brion Vibber]

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