[Foundation-l] Strategy document?

Fri Oct 3 20:23:47 UTC 2008

Hoi,
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
noxious ?

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 ?

Thanks,
      GerardM

On Fri, Oct 3, 2008 at 9:23 PM, John at Darkstar <vacuum at 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.
>
> 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
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>