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