[Foundation-l] Strategy document?

[John at Darkstar]

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 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
> 

_______________________________________________
foundation-l mailing list
foundation-l at lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l