The deletion process is interesting... it is not working on "our side" and
certainly not from a newbie's side. Now the question is not if it is wrong,
or why you want to change it but WHAT are you going to change and HOW will
this affect the observable issues in a positive way (the issue is to prevent
the large amount of false negatives). From any perspective, there is nothing
strategic if all you have is a realisation that something is wrong...
So PLEASE do not only say what is wrong, Discuss how you think an issue can
be solved. What needs doing... Many issues do not need a technical solution
and really we do not have enough developers. (What gives you that idea ???)
What I am missing in much of the discussion is how we are going to make our
community more of a community.. This is a recurring theme. It is true, we
have some 700 odd communities in loads of languages. At this moment only
those that speak English have a fighting chance to be heard. All the others
are not heard at all because how can you hear and understand them as well?
Within one of our communities we have them and us. We have admins villifying
other admins, and or users. We have people deleting articles that became
recognised for their quality. What makes the processes that are involved so
There are an increasing amount of studies done on the Wikipedia phenomena.
There are research mailing lists, research wikis... The way I see it, there
is hardly any strategic use comming out of it because we have not asked our
questions to the researchers... I want to know for instance what the effect
is of the quality of localisation on both our editors and readers. I want to
know how much use Commons is for the projects that use other scripts. What
are your questions ?
On Fri, Oct 3, 2008 at 9:23 PM, John at Darkstar <vacuum(a)jeb.no> wrote:
Somehow I believe we have enough developers (!) but we
have a lack of
community support of them. ;)
You have a lot of good points, especially on the deletion process. It
work from our side, but probably not from the newbie's side.
I think good ideas somehow isn't enough because the community somehow
stick to the ideas they know. How to initiate an open discussion, well I
don't know. Perhaps some discussion pages, but not on a technical place,
the users we want input from are to easily scared away. People without a
technical background won't discuss technical issues, and developers has
difficulty to address other about technical matters. Not to mention hmi
isn't a developers strongest capability, the interactions tend to be to
complex because "it's easy!"
Of the things you mention I think the deletion process is the single
most important thing because I suspects we are loosing contributors
because of this. It has both to do with the deletion process and the
lack of possibility to test how things work. Turned around I believe
that a users contribution should go to a temp area until he finishes,
and then he should still have a link to his contribution if it is refused.
Brion Vibber skrev:
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
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
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
== 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
* 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
* 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
The little things matter too. :)
Any idea how we can involve the community in
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 Vibber skrev:
>> John at Darkstar wrote:
>>> Is there any strategy document that describes what kind of
> 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? :)
foundation-l mailing list
foundation-l mailing list
foundation-l mailing list
foundation-l mailing list