Progress by March 14 ?

[Erik Moeller]

There will be a big Board + Staff meeting in Florida next weekend. It
would be really helpful to be able to show something with regard to
revision annotation / stable versions. Will it be possible to get some
prototype or at least mock-up up by March 14?

[Joerg Baach]

Hi Erik,

Post by Erik Moeller
revision annotation / stable versions. Will it be possible to get some
prototype or at least mock-up up by March 14?

I hope to have some simple form of prototype running on my server by
then (will be ugly, though). No promise, though.

Yours,

Joerg

[Erik Moeller]

Post by Joerg Baach
I hope to have some simple form of prototype running on my server by
then (will be ugly, though). No promise, though.

Saw the first code going in .. more coming?

NB: You may want to keep the branch you are making of the MW trunk
separate from the extension, which doesn't need a branch and can just
be committed directly into the extensions/ folder on
svn.wikimedia.org. The extensions/ directory in the phase3 module is
meant to remain empty. Ideally there should only be minimal changes in
the branch (new hooks etc.) and these can maybe even be merged into
trunk quite a while before the main extension is ready.

[Joerg Baach]

Hi Erik,

Post by Erik Moeller
Saw the first code going in .. more coming?

Working on it ;-)

Post by Erik Moeller
NB: You may want to keep the branch you are making of the MW trunk
separate from the extension, which doesn't need a branch and can just
be committed directly into the extensions/ folder on
svn.wikimedia.org. The extensions/ directory in the phase3 module is
meant to remain empty. Ideally there should only be minimal changes in
the branch (new hooks etc.) and these can maybe even be merged into
trunk quite a while before the main extension is ready.

I see your point, and will correct a bit later on. Atm I am still
bringing the different pieces of the puzzle together, and mainly checked
stuff into svn because of Brion asking me to make my development
developer-hits-bus (tm) save ;-)

Ah, there is an instance on

http://baach.de/phase3, running the extension.

Cheers,

Joerg

[P. Birken]

Post by Joerg Baach
Ah, there is an instance on
http://baach.de/phase3, running the extension.

Aha! So the database now allows for mutiple flags and these can be
set. Is the process already logged in some way?

Cheers,

Philipp

[Joerg Baach]

Hi Phillip,

Post by P. Birken
Aha! So the database now allows for mutiple flags and these can be
set. Is the process already logged in some way?

Logged - as in writen to some logging facility? Not yet, but I went down
the users can override option (could be disabled in the ui later on),
and store every change anyhow.

Cheers,

Joerg

[P. Birken]

Post by Joerg Baach
Logged - as in writen to some logging facility? Not yet, but I went down
the users can override option (could be disabled in the ui later on),
and store every change anyhow.

Yes, for transparency reasons, almost everything is logged or stored
somehow. Thus, there is the version history, but also the log, which
is accessible via Special:Log. However, I just see that we did not
specifically include this in phase I. So this should probably be a
part of phase II?

Bye,

Philipp

[Joerg Baach]

Hi Phillip,

Post by P. Birken
Yes, for transparency reasons, almost everything is logged or stored
somehow. Thus, there is the version history, but also the log, which
is accessible via Special:Log. However, I just see that we did not
specifically include this in phase I. So this should probably be a
part of phase II?

I assume its just just a couple of lines and well documented - should
not be a problem at all...

Cheers,

Joerg

[Daniel Arnold]

Post by Joerg Baach
Ah, there is an instance on
http://baach.de/phase3, running the extension.

Thanks a lot for the update. However I am bit concerned on interface issues
with the drop down lists and with too many different flags (and to many
quality scales for exach flag).

In Wikipedia article changes quickly get quite huge (much more than one screen
page, worst case in that respect are systematical typo and comma corrections
in an article) it is better to place the flagging buttons in between the
difference and the text, like in this mockup here:

Loading Image...

Otherwise people either tend to skip reading parts of the diff or have to
scroll again up after they did fully read it.

The drop down boxes: They need two mouse clicks, you can't grasp them without
exploring them and drop down lists are prone to wrong selections. So a button
like feature (or a button like link like the infamous "revert button" feature
of admins, see also above screenshot) is more convenient.

So each flag only needs one button: The "apply" button. It is not desireable
to uncheck again a tagged version (see my previous email for the detailed
rationale).

As well different quality scales for each flag such as "unvandalised"
and "superb" (and possibly more) tend to create a vote point system. Honest
people waste to much time in giving a grade according to their judgement and
dishonest people always take the highest grade. This social proplem alone has
the potential to provoke new kinds of flames and trolling (flames about the
right grade and such). Furthermore too much differenceiasation makes the
system more complicated for the user.

So I advocate for a system that is not too generic in a technical way and
which consists of single click through flagging (on diff view).

Keep up the good work,
Daniel Arnold / Arnomane

[Erik Moeller]

Hello Daniel,

I don't think this UI was really ready for criticism yet :). Please be
a little patient, at this time Joerg is just trying out a way to
implement the required feature set, we can always make it prettier
later. And the required feature set does include the capability for
multiple quality types / different dimensions, even if the use in the
de.wikipedia case might be very simple at first.

Post by Daniel Arnold
So I advocate for a system that is not too generic in a technical way and
which consists of single click through flagging (on diff view).

Joerg has a specific set of specifications to work with; these will be
implemented. Flexibility on the backend does not make it impossible to
implement UIs for specific use scenarios.

[Daniel Arnold]

Post by Erik Moeller
I don't think this UI was really ready for criticism yet :).

I know that it is a very early stage which mainly is technical work behind the
scenes such as how to store the items and how to connect it with the default
MediaWiki framework. As the interface does reflect the storage part to a
certain degree I think it can be helpful to discuss some logical aspects of
the UI (I am not talking about default font size, alignment, CSS and
friends ;). Drop down boxes vs. buttons is something which potentially
affects the technical internals.

Ok you could say (in pseudocode):

if (flag = single_item and unset_flag = false)
use buttons or plain links
else
use drop down boxes
endif

But I suppose it is easier to do something like this if you have it in mind
from the beginings on. That's what I want to make sure.

My main aim is to avoid double work and also to avoid that this extension
evolves into something too complex.

Post by Erik Moeller
Please be a little patient, at this time Joerg is just trying out a way to
implement the required feature set, we can always make it prettier
later. And the required feature set does include the capability for
multiple quality types / different dimensions, even if the use in the
de.wikipedia case might be very simple at first.

Well especially a simple flag unsetting can't work within a wiki (regardless
which one). Flag unsetting feature is equal to quality vote wars.

Post by Erik Moeller
Joerg has a specific set of specifications to work with; these will be
implemented. Flexibility on the backend does not make it impossible to
implement UIs for specific use scenarios.

Hm all my comments are based on the feature set and specifications that were
discussed about in public and which are written down in the de.wikipedia
wiki. Are these the same? I am a bit confused.

Anyhow I want to say thank you for the nice work done so far and I am really
looking forward.

Cheers,
Daniel Arnold / Arnomane

[P. Birken]

Post by Daniel Arnold
Well especially a simple flag unsetting can't work within a wiki (regardless
which one). Flag unsetting feature is equal to quality vote wars.

Yes, this danger is there. And you are right for the sighted-flag, but
not for reviewed, as there the flag has a lot of meaning. Therefore,
it should be possible to remove the flag in case of errors. I believe
if the reviewer participate in "flag-wars", then the choice of
reviewers is to blame and not the feature.

Post by Daniel Arnold
Hm all my comments are based on the feature set and specifications that were
discussed about in public and which are written down in the de.wikipedia
wiki. Are these the same? I am a bit confused.

These are nearly the same. The exact feature set that Erik and I
decided on and that Joerg will implement is described in Eriks mail to
this list from 28. Februar 2007 17:36.

It is essentialy what is written in de.wikipedia, but more precise in
some parts, for example regarding templates and is a bit more flexible
in some parts, for example in stating that there will be not 2, but
multiple flags possible.

Bye,

Philipp

[Joerg Baach]

Post by Erik Moeller
Saw the first code going in .. more coming?

Tiny bit more in, but beware - this is me finding out how to do things,
not clean or save code. Also I am committing quite often, so that you
have a backup all the time ;-)

Cheers,

Joerg