Since you'd be editing wikidata rather than the local wiki, could there be policy concerns here?

In T90765#1088921, @Krenair wrote:

Since you'd be editing wikidata rather than the local wiki, could there be policy concerns here?

The privacy policy is the same, but obviously you need a CC0 license warning and the anon edit notice (for logged out users).

I wonder whether a bot is / scanning all Wikipedias adding the first sentence to the article as the description of the corresponding Wikidata item. Doing that work manually is no fun and very time consuming.

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

an edit pencil now appears to the right of the article title

when tapped, an interface now appears for editing article description

enter a description, then tap save

now the article has a description, and if you were logged in the edit is properly attributed!

search can now use the new description too

This feature was developed as a prototype but it is still not implemented in production, correct?

@Qgil - not in production yet - going through code review and some design / UX refinements atm.

@Vibhabamba - if you have time, lets chat about some of the UX stuff we mentioned during the showcase meeting. i.e. making it easier to see first paragraph when editing descrips - turns out it's actually really tricky as the keyboard comes up leaving you with very little room... also can be confusing if you see too much clutter - i.e. the editing interface + keyboard + sample descrip + first paragraph... hmm...

@Mhurd agree about too much going on if we display it all at the same time.

Notes for Design Iteration:
Call to action/Icon needs iteration

Product Deliberations:
List wikidata and other abuse/vandalism filters employed (Even though Wikidata has this, its important for the team to know what filters we are running )
Using a more universal example that applies to a larger category (Place/person/event) might be bit more useful to users
@jkatz to add productizing/research comments

Communications:
This is a low barrier to entry edit funnel. We *could* socializing the feature if we don't see vandalism after a test period.

Some friendly suggestions:

• Consider adding a specialised tag for edits to the Wikidata description. That way, edits to descriptions via the app could be easily tracked and curated on Wikidata.
• It's possible that the existing tag is enough: https://www.wikidata.org/w/index.php?title=Special:RecentChanges&tagfilter=mobile+app+edit
• When this is being rolled out or tested, this should be socialised to the Wikidata community so they're aware of it.
• You can use this tag to perform quantitative analysis of how many of the description additions were reverted. This hard numerical evidence can be used to evaluate the success of the feature.

somewhere / somehow, it should be mentioned that their contributions to Wikidata (via the app) are CC-0 license.

@Deskana @aude good points! :)

Note that there is a functional work-in-progess patch here: https://gerrit.wikimedia.org/r/#/c/215074/

We are trying to help all open tasks listed under "Work continues after Lyon" at the Wikimedia Hackathon 2015 workboard finding their best way forward.

• If you are participating in Wikimania, consider adding the Wikimania-Hackathon-2015 project to get this task in that loop, which is about to start.
• If you think this project could welcome help from a dedicated Google Summer of Code or Outreachy intern, or from an Individual Engagement Grant, add the Possible-Tech-Projects project.
• If you would like to receive some other type of support (organizing a Tech Talk, establishing contacts with existing developer teams in Wikimedia or elsewhere, travel sponsorship for a related activity... you name it), please create a subtask explaining your request and associate it with #Engineering-Community (or you can start by commenting here if you prefer).
• Keeping the description, priority and assigned fields up to date always helps. :)

For some context about this message, see T101151: Evaluate which projects showcased at the Wikimedia Hackathon should be supported further. It is the last communication related to Wikimedia-Hackathon-2015 that we will post here.

@Vibhabamba @Mhurd

@Deskana stole my thunder on specialized edit tags (essential for tracking quality) and community engagement. I guess it was his thunder to begin with...

Other essentials:

• what about protected articles? They are not necessarily protected on wikidata--I would hate to see Barack's page get vandalized and have nobody fix it because our most active community only looks on desktop.
• small % rollout + kill switch
• more relatable example
• abuse filter documentation
• do we have validation criteria? Might need character limit and cut-off rules.

Not a blocker

• It would be great if we could somehow pull an example from something in the same 'category'. By this I mean with the same wikidata 'instance of' property value. If instance of = human, then we might even pull 'occupation'. That way looking up a painter would show you an example from another painter. If there isn't anything with a description, then we could rely on a default. I don't see this as a blocker for a % rollout with a kill-switch.

What not to worry about:

• I don't think we should worry about specific instructions and criteria at this stage. This belongs to the community to decide and currently the variety is one of the coolest things about descriptions.
• I don't think we need to be concerned with edit wars yet--casual users wont notice if it gets reverted, experienced users will know what to do. Let's see how it plays out...

@JKatzWMF:

• The boiled down usage example and text @Mhurd, @Deskana and I came up with at the hackathon reflect the Wikidata community's instructions. Use that and you should be good to go.
• protected articles: We need to figure out what's worse - not being able to edit a vandalized description or being able to vandalize one. From the feedback I got the former is much worse for people.
• Edit wars: @kaldari is talking about edit wars between Wikipedia and Wikidata editors over what is shown on the Wikipedia article vs what's useful for Wikidata. This is already happening and causing grief. See my comment at https://phabricator.wikimedia.org/T97566#1337875 please.

Screenshot of the abuse filter message received when trying to enter an expletive for a description:

Need information on the hard limit that exists within wikidata for submitting a description.
Lydia_Pintscher said she would provide details here.

Mobile Web Related Tickets:
https://phabricator.wikimedia.org/T101719
https://phabricator.wikimedia.org/T94713

The 'Write Description' interface needs to be mention the license under which the reader is submitting the contribution.

@Lydia_Pintscher

Upon further reflection I actually think we actually can't do description editing if Wikidata overloads the "description" field with a delimiter to accommodate the "internal usage notes" :(

Here's why:

We know the field has some size limit, for the sake of argument say 256 characters.

If "description" is overloaded to also contain internal usage notes following some delimiter, we now not only have to strip these notes out in every single place the description needs to be displayed (already half a dozen places in the apps alone), but we also then have to strip the internal usage notes and delimiter out when a user edits the actual description, and we'd have to re-add the internal usage note and delimiter *back* in when we saves the description - otherwise editing would destroy the internal usage note.

Presuming all of that, say a pre-existing note of, oh, 200 characters already exists - this means when we present the editing interface, we actually only have 56 characters which the user can use for a description. Say the internal usage note is 256 chars - this means we cannot have a description *at all*.

Does this make sense?

@Vibhabamba @JKatzWMF ^

@Mhurd @Lydia_Pintscher thanks for the heads up--this is a great example of why we do not overload fields in a database and why wikidata should strongly reconsider adding a separate field for instructions if they feel it is necessary.

how common are these "instructions" in wikidata? I realize the items for "male" and "female" have them, but then they have no site links (https://www.wikidata.org/wiki/Q6581097) so think would never appear in the wikipedia app.

also, I notice (at least in android), we don't show descriptions if they are too long (more than two lines). Not sure how we would handle them with editing (maybe show, but truncate with "..."). If editing / adding is possible then I think it's important to show something (the fact that there is a description)

In T90765#1366492, @aude wrote:

how common are these "instructions" in wikidata? I realize the items for "male" and "female" have them, but then they have no site links (https://www.wikidata.org/wiki/Q6581097) so think would never appear in the wikipedia app.

My guess would be at least a couple dozen with sitelinks. People have been using descriptions to prevent mistaken uses of the instance-of property. For example, "person" (Q215627) has a note pointing editors to Q5 for instance-of uses.

In T90765#1357678, @Mhurd wrote:

If "description" is overloaded to also contain internal usage notes following some delimiter, we now not only have to strip these notes out in every single place the description needs to be displayed (already half a dozen places in the apps alone), but we also then have to strip the internal usage notes and delimiter out when a user edits the actual description, and we'd have to re-add the internal usage note and delimiter *back* in when we saves the description - otherwise editing would destroy the internal usage note.

Presuming all of that, say a pre-existing note of, oh, 200 characters already exists - this means when we present the editing interface, we actually only have 56 characters which the user can use for a description. Say the internal usage note is 256 chars - this means we cannot have a description *at all*.

I don't follow. Why not just set the character limit to 256 minus the number of characters used by the usage note? I think it's reasonable to assume that that will be enough space.

@Jkatz and I chatted about the case where users paste the first two sentences as a description.
We should think about handling this case.
In the case where the user reads all these 3, there is a fair bit of repetition.

Rationale:

1. First the use reads the search results
2. Then he scans the description
3. Then he reads the lead section.

This way the same content gets repeated 3 times instead of twice.

@Mholloway - is there any way to identify the category of the article?
We can provide better help for the user who is editing the description if we know the category. (Description styles vary based on category)

This may not be required for MVP, but it might help in the future if we find users struggling with descriptions. Wikidata provides specific guidance based on category. For instance style for describing an article about a person (BLP's) is Country > Career.

Recently requested in OTRS Ticket#2016081410007397

Related: Android Wikidata description editing ticket:
https://phabricator.wikimedia.org/T146641

@Nirzar @cmadeo @RHo

This is the wikidata descrip editing ticket from my Lyon hackathon project - lots of screenshots and discussions... even a youtube video link at the top.

Untagging Android, since our work on this is tracked in T145813