Page MenuHomePhabricator

Please do not add gallery to technical campaign pages
Closed, DeclinedPublic

Description

Author: romaine.wiki

Description:
I heard today that a developer wants to add soon some kind of gallery/show to the campaign pages on Commons like on https://commons.wikimedia.org/wiki/Campaign:wlm-nl . It is scheduled to be live next week.

That we have these pages for campaigns is because of the problems of previous years that users (like admins) changed the campaigns unwantedly and caused us a lot of trouble. There were two key problems that caused us all the troubles: 1. there was no history to see what was changed, 2. the technical pages for campaigns were visited by too much people and altered too often the wrong way. The first problem was solved by the new campaign namespace. The second problem has been solved by having only one person responsible for maintaining and setting up the campaigns, with no links to the technical campaign pages to avoid users going there,

We absolutely do not want to have the public visit these pages as they are highly sensitive and purely for technical maintenance. To get the perspective. In 2012 alone, more then 365,000 images were uploaded during the month September through the campaigns. It is a contest we want to have it run smoothly without any problems and the last thing we want is to have people visiting the campaigns as too many people can change them.

There is no reason at all for users to visit these technical pages and we want as less as possible users to visit these maintenance pages. None of the uploaders will see this page, none of the local organizers is led to it, on purpose! Last year we led many users to it and let to a lot of trouble.

It was one of the biggest problems of last years competition and we absolutely do want to prevent that to happen again.


Version: unspecified
Severity: blocker

Details

Reference
bz53570

Related Objects

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:05 AM
bzimport added a project: UploadWizard.
bzimport set Reference to bz53570.
bzimport added a subscriber: Unknown Object (MLST).

romaine.wiki wrote:

PS: It is fine to have somewhere a page to show the last 50 images, but absolutely not there.

I understand the concern, but this seems like a completely manageable problem through access permissions, no? As far as I can tell, nothing in Yuvi's changes breaks the history or editability of campaigns.

  1. It is already editable only by admins and people with the specific right. Not many people.
  2. You can revert/rollback with a single click.
  3. Watchlists work.
  4. You can put these under full protection if you want.

I understand these problems existing with the previous implementation, but they don't apply now - they are just wiki pages, no? You've the full set of tools available for fighting vandalism on a wiki for these pages too. And since the total number of people who have permissions to edit these is also fairly low (just admins + a few other people who have the specific right), I don't see how this would be a problem.

Getting user friendly campaign pages out that can be shared with people who are interested in contributing was one of the goals for the Campaign: namespace(see mediawiki.org/wiki/User:Yuvipanda/Campaigns_namespace proposal), and I think it is worth doing.

romaine.wiki wrote:

Roughly the same amount of users have access to it as last year, admins and a special user group can edit. This caused us a lot of trouble last year.

The organizational team decided that we want to have a history page plus we want to prevent the problems of last year, and the best way to do that is having only one person who is maintaining them and not leading everyone to the pages. We are working with this and that works fine. (If those admins want to help in campaigns of other projects, that is not our concern.)

In the past there have been a lot of discussions how to set up this competition of Wiki Loves Monuments, which most users who can edit have no knowledge of, which caused last year that a lot of changes were made which had to be restored afterwards. That is something we do not want this year.

Working link: https://www.mediawiki.org/wiki/User:Yuvipanda/Campaigns_namespace_proposal

I disagree on Campaign: namespace pages being 'technical' pages. The whole point of the namespace has been to make it easier for people to contribute in a guided, specific way (think Wikiprojects, but more commons-oriented?). This patch actually makes them 'non-technical' and useful for everyone, and I think that is a good thing.

(More info: https://gerrit.wikimedia.org/r/#/c/81453/ is the patch being discussed, and http://blue-dragon.wmflabs.org/wiki/Campaign:show-off-campaigns is a demo of it)

romaine.wiki wrote:

(In reply to comment #3)
Admins can edit protected pages... protection is useless.

Between an edit and the discovery there can be a whole night in between, with thousands of pictures uploaded in the mean time that possible do not have the right templates and other requirements on them. We are talking here about an official contest, not just uploading.

These problems certainly will be back again this year of this is implemented.

And since the
total number of people who have permissions to edit these is also fairly low
(just admins + a few other people who have the specific right), I don't see
how this would be a problem.

That is what you could have said last year as well but the practice showed otherwise! Those admins (currently 270) + users with edit rights of campaigns gave us a lot of trouble.

Getting user friendly campaign pages out that can be shared with people who
are interested in contributing

We have never planned nor wanted to use these technical campaign pages for regular users, but only for technical staff of the contest.

To repeat what I had said previously on IRC - all of Romaine's points make perfect sense... in the older implementation of UploadCampaigns. There was no history, no rollback, no watchlist, nothing. If someone makes an error, it was hard to recover from, since they were just text fields with no history - no revert. So the WLM folks were wary of other people editing it without understanding what was going on, which was a totally legitimate concern. (See bug 30645)

None of these apply to the current implementation - which is just a wiki page, and has all the inherent advantages of a wiki page. I'm hoping we don't have to block a rather nice (IMO?) feature for fear of vandalism from other admins.

swalling wrote:

(In reply to comment #0)

I heard today that a developer wants to add soon some kind of gallery/show to
the campaign pages on Commons like on
https://commons.wikimedia.org/wiki/Campaign:wlm-nl . It is scheduled to be
live
next week.

That we have these pages for campaigns is because of the problems of previous
years that users (like admins) changed the campaigns unwantedly and caused
us a
lot of trouble. There were two key problems that caused us all the troubles:

there was no history to see what was changed, 2. the technical pages for
campaigns were visited by too much people and altered too often the wrong
way.
The first problem was solved by the new campaign namespace. The second
problem
has been solved by having only one person responsible for maintaining and
setting up the campaigns, with no links to the technical campaign pages to
avoid users going there,

We absolutely do not want to have the public visit these pages as they are
highly sensitive and purely for technical maintenance. To get the
perspective.
In 2012 alone, more then 365,000 images were uploaded during the month
September through the campaigns. It is a contest we want to have it run
smoothly without any problems and the last thing we want is to have people
visiting the campaigns as too many people can change them.

There is no reason at all for users to visit these technical pages and we
want
as less as possible users to visit these maintenance pages. None of the
uploaders will see this page, none of the local organizers is led to it, on
purpose! Last year we led many users to it and let to a lot of trouble.

It was one of the biggest problems of last years competition and we
absolutely
do want to prevent that to happen again.

It sounds to me like the problem had to do with changing of the campaign settings in a way that was not transparent and accountable. Putting the configuration for a campaign into a wiki page largely solves this problem, because whoever is visiting it, you have 1) built-in permissions, such as protection, to prevent undesirable editing and 2) you have a revision history to track down.

romaine.wiki wrote:

(In reply to comment #5)

Working link:
https://www.mediawiki.org/wiki/User:Yuvipanda/Campaigns_namespace_proposal

I disagree on Campaign: namespace pages being 'technical' pages. The whole
point of the namespace has been to make it easier for people to contribute
in a
guided, specific way (think Wikiprojects, but more commons-oriented?). This
patch actually makes them 'non-technical' and useful for everyone, and I
think
that is a good thing.

(More info: https://gerrit.wikimedia.org/r/#/c/81453/ is the patch being
discussed, and
http://blue-dragon.wmflabs.org/wiki/Campaign:show-off-campaigns
is a demo of it)

You can sure link to a page you created, but we haven't reviewed it or we haven't read in the text. It hasn't been discussed and are only now confronted with it. If we had seen this before and realized what this part of the plan was we certainly would have protested.

In the whole upload wizard/campaign users never get on this technical page, yes technical is what it is. Before it was a special page, but was moved to an own namespace to enable to see the history and more (as we did request), certainly not to make it easier to contribute - that was the biggest problem last year - it was already too easy to edit and we certainly do not want to make it more vulnerable to that.

(In reply to comment #9)

You can sure link to a page you created, but we haven't reviewed it or we
haven't read in the text. It hasn't been discussed and are only now
confronted
with it. If we had seen this before and realized what this part of the plan
was
we certainly would have protested.

Err, this was posted to village pump on commons, to the commons mailing list and to the WLM list.

In the whole upload wizard/campaign users never get on this technical page,
yes
technical is what it is. Before it was a special page, but was moved to an
own
namespace to enable to see the history and more (as we did request),
certainly
not to make it easier to contribute - that was the biggest problem last year

it was already too easy to edit and we certainly do not want to make it more
vulnerable to that.

There might have been a misunderstanding here - the idea is to get people to contribute *to* the campaign by Uploading photos - and *not* encouraging them to edit the campaign metadata itself.

romaine.wiki wrote:

(In reply to comment #7)

To repeat what I had said previously on IRC - all of Romaine's points make
perfect sense... in the older implementation of UploadCampaigns. There was no
history, no rollback, no watchlist, nothing. If someone makes an error, it
was
hard to recover from, since they were just text fields with no history - no
revert. So the WLM folks were wary of other people editing it without
understanding what was going on, which was a totally legitimate concern. (See
bug 30645)

None of these apply to the current implementation - which is just a wiki
page,
and has all the inherent advantages of a wiki page. I'm hoping we don't have
to
block a rather nice (IMO?) feature for fear of vandalism from other admins.

No, in the current suggested implementation they still make sense. It has been made easier to track changes, but still as much as users as last year can edit these campaigns and we do not check our watchlist 24 hours a day the whole month. We learned our lesson last year: we must not advertise these campaigns and we must not lead people to these pages because that had led to trouble in 2012. That it can be detected and reverted easier, doesn't solve that problem.

I wouldn't call it vandalism of admins, but a lot of changes were made last year in good faith, but were terrible wrong and can damage the contest. We are organizing the largest photo competition in the world, we have specific rules to follow of which most admins/etc aren't aware of.

The problem lies not in the feature but in the place of the feature. I think the feature is great, but potential harmful (as seen last year) on these pages.

romaine.wiki wrote:

It sounds to me like the problem had to do with changing of the campaign
settings in a way that was not transparent and accountable. Putting the
configuration for a campaign into a wiki page largely solves this problem,
because whoever is visiting it, you have 1) built-in permissions, such as
protection, to prevent undesirable editing and 2) you have a revision history
to track down.

Admins can edit protected pages...
Who caused the problems in 2012: admins + users with the right to edit the campaigns.

romaine.wiki wrote:

(In reply to comment #10)

Err, this was posted to village pump on commons, to the commons mailing list
and to the WLM list.

What I have read there is an update of the upload campaigns to a new system with history, which we all agree on.

It is this particular aspect that is missed completely. On your page I haven't read it that this was meant. I think a large part of the misunderstanding is then caused by the description on your page that to me hasn't made clear that this was the outcome.

Quoted from your page:

Images uploaded via that Campaign so far

I had read that that would be like on the campaign page that people visit (like https://commons.wikimedia.org/wiki/Special:UploadWizard?campaign=wlm-nl ), or a category with these files or something like that, but not on the technical page. Last week we noticed that the uploaded files are automatically added to a category for each campaign which was automatically done by the campaign.

Another quote from that page:

Functionality developed for getting 'Images uploaded via this Campaign' can be used in many different places (such as the Mobile app)

Also another line we certainly did not read there that it would be the technical page of the campaign.

There might have been a misunderstanding here - the idea is to get people to
contribute *to* the campaign by Uploading photos - and *not* encouraging them
to edit the campaign metadata itself.

The whole navigational structure we have built the previous years and this year is that participants visit our website, list on Commons or list on Wikipedia, click there directly on the upload link to upload files, and they never ever come on the technical page. Our intention is even to not telling the technical pages exist, they have nothing to do there. We are happy with that situation that just as last year participants can easy upload without any difficulties.

swalling wrote:

(In reply to comment #12)

It sounds to me like the problem had to do with changing of the campaign
settings in a way that was not transparent and accountable. Putting the
configuration for a campaign into a wiki page largely solves this problem,
because whoever is visiting it, you have 1) built-in permissions, such as
protection, to prevent undesirable editing and 2) you have a revision history
to track down.

Admins can edit protected pages...
Who caused the problems in 2012: admins + users with the right to edit the
campaigns.

If you can't agree with other Commons admins and regular users about how/when campaigns should be changed or updated, then you have a social problem to solve, not a technical one. You need to get some kind of consensus or policy in place, not ask Yuvi or other developers to lock down or obscure campaign pages.

(In reply to comment #12)

Admins can edit protected pages...
Who caused the problems in 2012: admins + users with the right to edit the
campaigns.

What problems, exactly? Do you have links to mailing lists / talk page conversations about what happened?

Changed title to remove the word 'technical'. Less loaded this way, I think?

romaine.wiki wrote:

It has nothing to do with agreeing with other admins/etc or not. Those other admins aren't aware of the detailed plan we are following and they have changed things as they do not know what the plan is. There is among the complete organizational team, including the national organizing teams, consensus about how we organize it. It all have been discussed.

Until today the whole organization went perfectly fine. We have done our homework well, we have prepared us well, we have discussed and searched for the best situation to enrich the Wikimedia movement.

This until an unknown tool was promoted, that we do not need, haven't asked for and wasn't discussed either this way. This tool attracts people to pages that we consider too fragile and to sensitive and we certainly do not want attract people to. If we would have known that this would be included in the update of the campaigns, we would not have agreed with the whole plan.

So no, it is not a social problem but a technical and communications problem.

Another point I must add, if I see the example page on wmflabs, we can't any long have a quick view on the campaign page to check for certain things as the complete page is buried under pictures we have never requested to see there. We have about 100 campaigns to manage...

romaine.wiki wrote:

(In reply to comment #16)

Changed title to remove the word 'technical'. Less loaded this way, I think?

Absolutely not. You caused already this communication problem, because you were unclear what you meant in your proposal, not again!

romaine.wiki wrote:

(In reply to comment #15)

(In reply to comment #12)

Admins can edit protected pages...
Who caused the problems in 2012: admins + users with the right to edit the
campaigns.

What problems, exactly? Do you have links to mailing lists / talk page
conversations about what happened?

Almost everything what could be changed in the campaigns, what should not have been changed, was changed at least one. Most of the conversation was at IRC, but this problem certainly has been mentioned on several places. (I think we haven't discussed it much in public as that was primary already the cause of the problem that people start changing them.

I will look if I can find public logs of feedback/meetings. I can also ask the users who have helped to check and restore it during the months August and September to comment on this matter.

(In reply to comment #13)

The whole navigational structure we have built the previous years and this
year
is that participants visit our website, list on Commons or list on Wikipedia,
click there directly on the upload link to upload files, and they never ever
come on the technical page. Our intention is even to not telling the
technical
pages exist, they have nothing to do there. We are happy with that situation
that just as last year participants can easy upload without any difficulties.

And nothing is preventing you from continuing to do that.

I'm going to disengage and continue my work unless you (or someone else?) actually raises issues that are relevant, and stop ignoring the fact that there exist tools to deal with 'admin vandalism' now, as apposed to last year.

(In reply to comment #4)

Those admins (currently 270) + users with edit rights of campaigns
gave us a lot of trouble.

Thanks for the flowsers. How can you say such a thing without a history? Maybe it was just *one* user?

It is still Commons what you are uploading to.

  • Use AbuseFilter if you really think it's required to restrict access.
  • Set up Editnotices telling not to change, ...

We have a per-page, per group and per-namespace edit notice:
https://commons.wikimedia.org/wiki/Template:Editnotices/Page/<fullpagename>
https://commons.wikimedia.org/wiki/Template:Editnotices/Group/MediaWiki:Abusefilter-warning-
https://commons.wikimedia.org/wiki/Template:Editnotices/Namespace/MediaWiki

romaine.wiki wrote:

I posted a bug earlier about the problems with the upload campaigns. I was realistic and mentioned only the technical part in the bug. (The organizational part we did ourselves.)

A colleague who helped out with the problem of changing campaigns wrote comment 19: https://bugzilla.wikimedia.org/show_bug.cgi?id=30645#c19

In the whole bug nothing that made clear that this tool was planned.

romaine.wiki wrote:

And nothing is preventing you from continuing to do that.

I'm going to disengage and continue my work unless you (or someone else?)
actually raises issues that are relevant, and stop ignoring the fact that
there
exist tools to deal with 'admin vandalism' now, as apposed to last year.

I find it disturbing that you do not take our problems seriously.

romaine.wiki wrote:

(In reply to comment #21)

(In reply to comment #4)

Those admins (currently 270) + users with edit rights of campaigns
gave us a lot of trouble.

Thanks for the flowsers. How can you say such a thing without a history?
Maybe
it was just *one* user?

It is still Commons what you are uploading to.

  • Use AbuseFilter if you really think it's required to restrict access.
  • Set up Editnotices telling not to change, ...

We have a per-page, per group and per-namespace edit notice:
https://commons.wikimedia.org/wiki/Template:Editnotices/Page/<fullpagename>

https://commons.wikimedia.org/wiki/Template:Editnotices/Group/MediaWiki:
Abusefilter-warning-
https://commons.wikimedia.org/wiki/Template:Editnotices/Namespace/MediaWiki

Just one user doing all kind of different things in different campaigns? We had about 45 different campaigns, a lot of different changes which were not the same nor related, while the complete contest is almost the same. We have asked on IRC if anyone edited, and asked them to stop, some changed stopped, other kept continuing.

Perhaps it sounds like flowsers to you, but we had to restore all the campaigns each time.

romaine.wiki wrote:

In January 2013 we had an evaluation about Wiki Loves Monuments. I cite:

Source: https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Evaluation

Romaine: bug https://bugzilla.wikimedia.org/show_bug.cgi?id=30645 (history for
changes in Upload Campaigns) needs to be fixed! Suggestion: let's try to
centralise things, not give the rights out to people so liberally – this
probably saves time in the long run. Have a specific group of users who do set
this up. A lot of users have no experience/feeling with templates, upload
campaigns, etc. And have a central person people can talk to regarding this
subject. (AP) Select a central coordinator for the Upload Campaigns

A summary of this above further on the page:

Cleaning up the mess (no history: bug 30645)

(In reply to comment #23)

I find it disturbing that you do not take our problems seriously.

I think Yuvi takes these problems seriously. But *I doubt* that hiding the campaign pages is a solution. I can only speak for myself, but I don't have the attitude to change something just because I saw it. If there would be a banner (edit notice) telling me to keep my fingers away and whom to contact in case of an emergency, I would of course do that. If you need even further access restriction, I suggest filing a bug for that.

Another point is that it's already hard enough for organizers to learn how to set up a campaign properly, including editing JSON. I am a bit concerned about the recent developments [VE, TemplateData, ...] that will more and more split the community into "techs" and content creators. In the end, no one knows what the other group does, fuelling speculations, lacks of appreciation, and unfounded fears like we had with our last checkuser election.

romaine.wiki wrote:

(In reply to comment #26)

(In reply to comment #23)

I find it disturbing that you do not take our problems seriously.

I think Yuvi takes these problems seriously. But *I doubt* that hiding the
campaign pages is a solution. I can only speak for myself, but I don't have
the
attitude to change something just because I saw it. If there would be a
banner
(edit notice) telling me to keep my fingers away and whom to contact in case
of
an emergency, I would of course do that. If you need even further access
restriction, I suggest filing a bug for that.

Let us compare 2012 with 2013 concerning wrong edits: in 2012 there were at least 30 unwanted changes were made before the start, in 2013 we have only 2 unwanted changes so far. Our policy on this matter is thought through and works.

If they make it technical too easy to edit then it becomes a social problem, while the origin was a technical change which wasn't needed nor wanted there.

There is no need for anything if this tool isn't implemented on these pages. And before any further access restriction is implemented - after been discussed - we are weeks away, while within a day the largest photo competition is going to start!

Another point is that it's already hard enough for organizers to learn how to
set up a campaign properly, including editing JSON. I am a bit concerned
about
the recent developments [VE, TemplateData, ...] that will more and more split
the community into "techs" and content creators. In the end, no one knows
what
the other group does, fuelling speculations, lacks of appreciation, and
unfounded fears like we had with our last checkuser election.

The tool is going to hide the whole setup that is human readable without knowing JSON. I have about 100 campaigns to maintain, I want to keep that overview as I am not that experienced in JSON. Implementing this tool makes it impossible for me to maintain all these campaigns.

I forgot to tell earlier, with thousands of uploads a day, it is not a solution to be able to revert wrong edits in campaigns, those can have a big impact with huge damage on the picture contest.

I must admit I skimmed this discussion, but from what I gather Romaine's concerns could be alleviated by setting $wgNamespaceProtection[NS_CAMPAIGN] to some group that contains only people who know what they are doing. (See https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection for details)

As a general principle, I don't think security through obscurity is a good solution to any problem.

I'm going to agree with Brian; this entire situation seems needlessly hyperbolic.

(In reply to comment #28)

As a general principle, I don't think security through obscurity is a good
solution to any problem.

Indeed.

If we really do have a problem with private data being placed on these pages, we can RevDelete the pages involved and block the users who do not understand how a wiki works.

The tool is going to hide the whole setup that is human readable without
knowing JSON. I have about 100 campaigns to maintain, I want to keep that
overview as I am not that experienced in JSON. Implementing this tool makes it
impossible for me to maintain all these campaigns.

I'm not very familar with campaign stuff, but would putting the current json-formatted-as-a-table structure still on the page, but at the bottom, in a collapsible section, be a good compromise on that point?

This is a 'culture problem', not a technical one, and Bugzilla is not the appropriate venue to scheme against other sysops you do not trust. If you think there is a serious need to restrict the editing of the Campaign: namespace, please open a bug as such (Brian's suggestion in comment 28 would work, for instance). This request, however, has run its course. Given consensus here, I'm going to mark this as WONTFIX.

Concur with James Forrester. This is cultural, not technical. Let's move on.

romaine.wiki wrote:

Is it not being able to maintain about 100 campaigns purely because it is hidden for a tool that seems to get implemented without any discussion, not a technical problem? Without the technical tool, planned to be implemented on that place, there was no problem at all.

I have no problem changing things, and we probably haven't made the right choices in the past in relation to the campaigns, but I/we have to be able to do my/our work.

Right, so, first, there's no patch.

Second, this is a cultural issue, not a technical one, so this is being closed WONTFIX.

Just to summarize a quick discussion I had with Romaine on irc:

Two main problems:

  • There is a large concern that people "being bold" has serious consequences, especially in the middle of a campaign. While its true there is still a history, and its easy to revert, the consequences are still large in the time until the revert happens. Increased exposure means people are more likely to "experiment" with a campaign page
  • The JSON structure rendered as a table is useful to campaign managers, who have some technical knowladge, but probably aren't "programmers" and find the raw json a little off putting. Campaign managers have to manage many campaigns, and it is important to be able to see the json structure at a glace (hence having it in a collapsible section is too hidden)

My suggested solution would be:
*For problem 1, $wgNamespaceProtection
*For problem 2, make the right used for namespace protection, also switch between displaying the fancy gallery thing, and the json table blob. .
**Personally, I also think it would be useful for people without the right who see the gallery, to still have a collapsible section at the bottom of the campaign page labelled "technical details" which shows the json rendered as a table. Wiki users are curious about these types of things, and like seeing technical details.

romaine.wiki wrote:

(In reply to comment #35)

Right, so, first, there's no patch.

Second, this is a cultural issue, not a technical one, so this is being
closed
WONTFIX.

Making it too difficult to maintain 100 upload campaigns because of a technical tool i a technical issue and not a cultural one.

romaine.wiki wrote:

(In reply to comment #36)

I think you describe the essence of the situation, a good summary. I couldn't have done it better.

(In reply to comment #36)

Wiki users are curious about these types of things, and like seeing
technical details.

+1

$wgNamespaceProtection

I this case, there must be clear instructions whom to contact. And sysops should be notified. Locking them out of their "own wiki" (cf. also translate extension) will certainly bring up-questions.

(In reply to comment #30)

If we really do have a problem with private data being placed on these pages,
we can RevDelete the pages involved and block the users who do not understand
how a wiki works.

I can't see how this is related to the issue here.

(In reply to comment #36)

My suggested solution would be:
*For problem 1, $wgNamespaceProtection

Actually this seems to already be the case:
$wgNamespaceProtection[ NS_CAMPAIGN ] = array( 'upwizcampaigns' );

Which limits it to people who are either "Upload Wizard campaign editors" or Admins. So I guess what is being asked for point 1, is to remove that right from admins?

I this case, there must be clear instructions whom to contact. And sysops
should be notified. Locking them out of their "own wiki" (cf. also translate
extension) will certainly bring up-questions

Yeah, for that sort of change, I would expect a discussion on [[commons:COM:VP]]

Romaine: If you are interested in seeing bawolff's proposal in comment 28 and comment 36 implemented, please feel free to open a new, clean report to request it, so it can be discussed. This bug report is already noisier than needed.

I'm going to close this as WONTFIX again for reasons in comment 14 and comment 32. Please do not reopen this report to express disagreement. Thanks for your understanding.

Rather than discussing about protections and unwanted changes, I would like to ask why the campaign page should be a gallery.

Currently, when you edit the campaign namespace you get the campaign configuration (in json). When you view the campaign page, you see the same data but formatted as a table.
Thus it is consistent.

However, the proposed change makes the Campaign a gallery while “editing” the gallery changes the campaign json. This seems wrong.
In my opinion, the «show uploads from this campaign» should be a Special page, linked from the breadcrumbs of Campaign namespace.

Or maybe the campaign page could have a few links at the top like:

  • Description
  • View uploads from this campaign link.
  • See a tutorial for configuring a campaign
  • Etc.

followed by its configuration

Another option would be creting a new action for viewing the Campaign configuration, but that seems wrong.

(In reply to comment #42)

Rather than discussing about protections and unwanted changes, I would like
to
ask why the campaign page should be a gallery.

Same reason Category pages include a gallery and File pages include an image view and metadata: it's a useful way of visualizing what's going on.

(In reply to comment #43)

(In reply to comment #42)

Rather than discussing about protections and unwanted changes, I would like
to
ask why the campaign page should be a gallery.

Same reason Category pages include a gallery and File pages include an image
view and metadata: it's a useful way of visualizing what's going on.

I guess there's really two separate things going on - How the campaign is configured, and the results of the campaign. I tend to agree that its good to show the results of the campaign, but I think the way the campaign is configured is also important information which should not be left at the wayside either (although having it hidden by default sounds reasonable to me).

There's really two different user groups who interact with campaigns. Campaign managers, and everyone else. They're both important groups, and even though one group is significantly smaller, both are still just as important. Our campaigns are much less likely to be successful if our campaign managers encounter problems. Although Romaine seems to be the only one complaining, given s/he is the main person managing campaigns (347/389 of recent edits or 89%), his/her opinion should perhaps be given more weight then we would normally afford a single person.

(In reply to comment #44)

There's really two different user groups who interact with campaigns.
Campaign
managers, and everyone else. They're both important groups, and even though
one
group is significantly smaller, both are still just as important. Our
campaigns
are much less likely to be successful if our campaign managers encounter
problems. Although Romaine seems to be the only one complaining, given s/he
is
the main person managing campaigns (347/389 of recent edits or 89%), his/her
opinion should perhaps be given more weight then we would normally afford a
single person.

I should point out that manually editing raw JSON blobs is a REALLY SHITTY USER INTERFACE.

It's great that one person likes it, but ..... that's not sustainable for most people. We want more people maintaining campaigns, NOT just one.

I should point out that manually editing raw JSON blobs is a REALLY SHITTY
USER
INTERFACE.

It's great that one person likes it, but ..... that's not sustainable for
most
people. We want more people maintaining campaigns, NOT just one.

Well the original complaint was that the change would force people to deal with raw json blobs more then was previously happening.

I don't think anyone has claimed they like dealing with raw json blobs.

(In reply to comment #46)

Well the original complaint was that the change would force people to deal
with
raw json blobs more then was previously happening.

That complaint appears to be wildly incorrect?

I don't think anyone has claimed they like dealing with raw json blobs.

Then.... why the complaint?

(In reply to comment #47)

(In reply to comment #46)

Well the original complaint was that the change would force people to deal
with
raw json blobs more then was previously happening.

That complaint appears to be wildly incorrect?

Original complaint as I understand it:

Previously campaign pages showed json formatted in a table structure. This was useful because people had trouble groking the raw json, especially when comparing a large number of campaigns. With the change, the configuration information is no longer pretty printed anywhere. As a result campaign managers must have the raw json open to figure out the configs, which is more difficult for them to understand at a glance.

Hence Romaine's complaint is about being forced to look at more raw json, which makes his/her job of managing the campaigns more difficult.

Brion, Romaine is THE person handling all WLM 2013 campaign editing, given the problems last years.
It is thus logical that he is the one complaining as he's pretty much the only one (re)configuring campaigns.

Oh, and I'm sure he doesn't like json. That's part of the reason he is asking so much that the pretty view isn't removed. I also think it's a bad interface, but I assumed a better editor was in the roadmap.

PS: I also asked some time ago for an inheritance/templating function, so that a WLM-xy campaign could contain everything defined for WLM-campaign-template, changing just the country parameter (plus a few bits which would be defined outside the template).

So... if we add back pretty-printed JSON of config with a simple UI to get at it, are we all happy?

This view (same as current JSON schema pretty-printer) would presumably be replaced with the nice data editing interface in future.

(To clarify, the "pretty view" *IS* the raw JSON data. It's just pretty-printed into a table.)

Ok, I've read the comment history in more detail, and chatted a bit with bawolff in IRC re: the history of the discussion.

It sounds to me like the actual problem is:

  • there's not an admin-friendly editing tool to list campaigns, show their settings, compare and edit them.

combined with the fact that:

  • existing campaign administrators have been using the JSON pretty-printer display and opening lots of Campaign: pages in separate tabs to facilitate viewing and comparing campaign configurations.

thus:

  • the particular workflow of opening lots of Campaign: pages in tabs and comparing the data in the table layout would be broken by showing different content on Campaign: pages without adding a configuration-view-edit tool.

Romaine, can you describe your workflow and requirements in a bit more detail?

Remember that we're not trying to remove features or encourage random people to edit campaign data -- we're trying to encourage end-users to actively use and submit to campaigns, which are *NOT* limited to Wiki Loves Monuments specifically but are meant to become much more generally usable.

If anything, switching the display from a big data structure to a prominent upload call to action should discourage people from editing the campaign pages, and encourage them to upload instead.

Looks like a good description. Plus also the really bad timing for general improvements to Campaigns the day before WLM (a heavy campaign user) begins.
Had this been on July or November, I'm sure it would have been a much nicer discussion.

romaine.wiki wrote:

(In reply to comment #42)
I like the idea of some kind of portal which show (like a gallery) all campaigns. With in it or below it some options like "view source" or "view settings", "upload to campaign", "see uploads with this campaign", etc. And clicking on an item shows the last 50 uploads.

(In reply to comment #43)

(In reply to comment #42)

Rather than discussing about protections and unwanted changes, I would like
to
ask why the campaign page should be a gallery.

Same reason Category pages include a gallery and File pages include an image
view and metadata: it's a useful way of visualizing what's going on.

I think it is better to compare it with system messages in the MediaWiki namespace. Those show also the code and not what has done with the code. Categories and file pages are in much different use than the campaign pages.

(In reply to comment #45)

I should point out that manually editing raw JSON blobs is a REALLY SHITTY
USER INTERFACE.

It's great that one person likes it, but ..... that's not sustainable for
most
people. We want more people maintaining campaigns, NOT just one.

It is not so much that I like it, in the past month I have learned to read them and getting used to them. When I work I need a total overview of something, the raw one doesn't give me that overview, while the table structure does (as I learned to understand what is doing what with what results). A need an overview to be able to do my work.

(In reply to comment #49)

Oh, and I'm sure he doesn't like json. That's part of the reason he is asking
so much that the pretty view isn't removed. I also think it's a bad
interface,
but I assumed a better editor was in the roadmap.

It is not so much liking or disliking it, I understand json is needed to let it work properly and I deal with it, that is ok. I also learned to deal with the table structure. But I need to have a overview of a campaign (we have about 100 of them for Wiki Loves Monuments), which the table structure gives me.

romaine.wiki wrote:

(In reply to comment #52)

Ok, I've read the comment history in more detail, and chatted a bit with
bawolff in IRC re: the history of the discussion.

It sounds to me like the actual problem is:

  • there's not an admin-friendly editing tool to list campaigns, show their

settings, compare and edit them.

I have created an overview page of all WLM campaigns for myself and that works pretty well. I have learned to read the table format and I can deal with the JSON code, so personally speaking the current interface is not the most optimal but works for me at the moment. As said, to be able to maintain the campaigns I need the table format as overview, while that seems to be hidden next week with the implementation. That is the first problem.

The second problem is perhaps the way how we as organizers have dealt with the campaigns. Participants and national teams expect us (the international team) to supply smoothly working campaigns in a contest that runs without big problems. In 2012 it appeared to work well in theory, but in practice we encountered problems. Problems with the potential of disturbing the contest largely. Looking back I think we should have had a evaluation with (more) technical people to discuss the problems of the campaigns of 2012. With the knowledge we had in January we have requested changes in the campaigns and have thought about how to minimize the risk of problems. Reading the comments in this bug it seems we should have requested more changes we had not thought of as we seem to use it know in a way it is not really meant to be.

combined with the fact that:

  • existing campaign administrators have been using the JSON pretty-printer

display and opening lots of Campaign: pages in separate tabs to facilitate
viewing and comparing campaign configurations.

Yes.

thus:

  • the particular workflow of opening lots of Campaign: pages in tabs and

comparing the data in the table layout would be broken by showing different
content on Campaign: pages without adding a configuration-view-edit tool.

Romaine, can you describe your workflow and requirements in a bit more
detail?

I am not having completely clear what you would like to know, but I'll try.
My workflow starts with: https://commons.wikimedia.org/wiki/User:Romaine/Wiki_Loves_Monuments/2013/table

This table gives me a complete overview of all relevant pages and campaigns. Originally the table was smaller but was extended each week with new columns to get everything ready in the end of this month.

Each row is a country, each column is a group of pages that perform a specific task. The /xx are language versions of pages used in that country. Almost all columns are used directly or indirect in the campaigns. Most rows represent in fact all pages for one campaign. I mostly search to fix the red links and red crosses. Many times when something is changed it is checked in the campaign, mostly the technical page, sometimes also the visual campaign how uploaders see it. Also requests from national teams I implement. I try to match the campaign itself with all specific aspects of the spoken languages, the local situation of the monuments, etc, in the campaign page everything comes together.

What my requirement is, is to be able to click in my table on a link that leads me directly to an overview page of all things put in the campaign, just as the table structure on the campaign pages gives me know.

Remember that we're not trying to remove features or encourage random people
to
edit campaign data -- we're trying to encourage end-users to actively use and
submit to campaigns, which are *NOT* limited to Wiki Loves Monuments
specifically but are meant to become much more generally usable.

I saw the new campaign pages and the overview of the campaign I use often was gone there.
For a large competition like Wiki Loves Monuments at first sight the campaigns do not seem to be vulnerable for much wrong edits, but there are many admins on Commons which can edit without having enough knowledge. I think, considering all the comments, it has been made too easy to edit the campaigns for too much people, but on the other hand I question myself if it is a good idea to limit access to campaigns in general as it will then be for other projects more difficult to edit campaigns due the smaller number of campaign editors.

I understand that the purpose of the new tool is to encourage end-users to use all campaigns more often, I really like it that that is to be improved, and I really want to support and help that to become better. As I wrote before, I think we can improve that much more by some kind of special portal page.

If anything, switching the display from a big data structure to a prominent
upload call to action should discourage people from editing the campaign
pages,
and encourage them to upload instead.

I haven't seen any campaign, not in WLM, nor other projects using upload campaigns, using the pages in the campaign namespace for anything else than technical maintenance and the flow of the users doesn't reach to the campaign namespace.

In general people which use a campaign to upload never visit these technical pages. They are directed to a upload campaign by a project page or website, only see an uploadform, and afterwards they see only the images they have uploaded. That is the same for Wiki Loves Monuments, we have three ways to go uploading through the campaigns. Participants find the website of the national team through the central notice, visit the website about the contest and click there on the campaign. Another way is to click directly on one of the links in the lists of monuments in Wikipedia, which pre-fill the campaign to easy the upload. Example on this page, the placeholder in the last column: https://en.wikipedia.org/wiki/List_of_monuments_of_Aruba The third way to use a campaign is to click on here: https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_upload

I still do not understand why the gallery has to be on the technical page while none of the visitor streams is going to that page, while it would be nice to have such tool for participants. I think there are better places to encourage people to upload. As said before, I like the idea of the gallery of the last 50 images uploaded, but only not there.

Within my task of the organisation of Wiki Loves Monuments I also look to the flow of the users through pages. There are certainly improvements that can be made and the participation can be enlarged. I am happy to talk about it how we have done it and to help with general improving this for end users.

To summarize:

  • For the maintenance we still need the overview pages that are currently shown on the pages in the campaign namespace. In the gallery page on labs it is gone.
  • The current JSON pages aren't a problem for the organizers. However they are vulnerable to wrong edits and gives us concerns. This can be discussed, but I think it is at the moment short term.
  • I am happy to talk about the flow of the user and enlarging the participation of users.

The first campaign gets active at 12:00 UTC due time zones, that is already in 10 hours and 20 minutes. As long as we have easy and direct access to the overview of the settings of a particular campaign (like https://commons.wikimedia.org/wiki/Campaign:wlm-nl ), there is no problem.

Thanks for the detailed comments, Romaine -- that helps a lot in making sense of this!

We'll continue to work on the gallery mode because we think it'll be useful for new non-WLM-related campaigns -- especially smaller campaigns that won't have as much human and tool infrastructure built specifically around them -- but we'll make sure nothing breaks for you while you're in the middle of things.

Sounds like we'll want to start putting together some tools to help with campaign maintenance; Yuvi's thinking about ways to best implement it.

Thinking about some shorter-term fixes...

It should be pretty easy to put in a second view mode that shows the current table view when you pass a link parameter -- this should just require a search-and-replace on your overview page if that's the only place you're clicking through to the data tables.

romaine.wiki wrote:

At the moment it is implemented exactly as it looked 2 weeks ago. This does not work for me.

romaine.wiki wrote:

Sorry, but that is not a realistic alternative on the workfloor.

I had to fix a campaign yesterday. As changes have a big impact, I always check my edits. Not simple and easy possible any more.

It is clearly the case that all comments I made here above are ignored. Comments based on practically use and not some sort of theory how campaigns should be used.

Because I am not able to do my work properly with these campaigns, I quit.

(In reply to comment #4)

Roughly the same amount of users have access to it as last year, admins and a
special user group can edit. This caused us a lot of trouble last year.

Unfortunately still missing some specific examples... I'm aware of comment 19 and comment 25 but I'd really appreciate some links so everybody can understand the problem better.

bawolff proposed potential solutions in comment 36 and I asked in comment 41 to create a clean ticket if interested in implementing this. To my knowledge, this has not happened.

(In reply to comment #59)

I had to fix a campaign yesterday.

Link to the diff is welcome.

It is clearly the case that all comments I made here above are ignored.

I understand that you are frustrated, but this is not true.
See comment 56 as latest example.

(In reply to comment #60)

Link to the diff is welcome.

https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-sk&diff=prev&oldid=103937065

and I agree that this isssue would have been easier to resolve with table representation of JSON data.

romaine.wiki wrote:

(In reply to comment #60)

(In reply to comment #4)

Roughly the same amount of users have access to it as last year, admins and a
special user group can edit. This caused us a lot of trouble last year.

Unfortunately still missing some specific examples... I'm aware of comment 19
and comment 25 but I'd really appreciate some links so everybody can
understand
the problem better.

Quick examples:
Should not have been removed, essential for the participation:
https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-cn&diff=102249331&oldid=102249049

Revert of wrong edit:
https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-us&curid=27388785&diff=102936603&oldid=102619960

bawolff proposed potential solutions in comment 36 and I asked in comment 41
to
create a clean ticket if interested in implementing this. To my knowledge,
this
has not happened.

Forgotten, I think I will create one soon.

(In reply to comment #59)

I had to fix a campaign yesterday.

Link to the diff is welcome.

I am happy to give a diff but I do not understand, why needed, But here it is:
https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-sk&diff=prev&oldid=103937065

It is clearly the case that all comments I made here above are ignored.

I understand that you are frustrated, but this is not true.
See comment 56 as latest example.

So far I can see is the recent change to the campaigns identical as planned in the end of August without any change to the problems described. As this change is strongly affecting the ability to work properly it looks very much like that the issues raised are ignored with the implementation. I am very happy that in this bug several users have helped to find a solution, but seeing no result while we are in the middle of the largest photography competition in the world where thousands of people rely on us, is indeed very frustrating.

bawolff proposed potential solutions in comment 36 and I asked in comment 41
to
create a clean ticket if interested in implementing this. To my knowledge,
this
has not happened.

Forgotten, I think I will create one soon.

For reference, Romaine did that with bug 54040

Gilles triaged this task as Unbreak Now! priority.Dec 4 2014, 10:11 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Needs Triage.Dec 4 2014, 11:23 AM