Page MenuHomePhabricator

Claim or assign an article
Open, Needs TriagePublic

Description

As an event participant, I want to claim or be assigned an article on the worklist, so that two people don't unknowingly work on the same article and duplicate effort.
Context: A recurring pain point across communities. Note the distinction between claiming an article to create versus claiming a task on an existing article, which affects scope.

Acceptance criteria:

  • A participant can mark an article as claimed, and this is visible to others.
  • The claimed state shows who claimed it.
  • A claim can be released or reassigned.
  • Decision recorded on whether claiming is per-article or per-task.

Related Objects

Event Timeline

some questions that came up for me about claiming:

  • how many people can claim an article? if there are more eyes wanted, should there be multiple claimers? should we set a maximum for claims?
  • what happens when someone claims an article? does the article appear disabled for everyone else, informing that the article shouldn't be 'touched'?
  • does the article get unclaimed automatically when, for example, the person who claimed it makes a couple of edits? or do they have to unclaim manually?

Good questions @JFernandez-WMF , and I think they point us toward a simpler design. What if we reframe this from "claiming" an article to "showing that an article is being edited"? Instead of a manual claim and release action, we surface a signal we mostly already have: recent edit activity on the article.

That reframe handles most of what you raised:

  • How many claimers / a maximum: not something we'd need to define. We just show who has recently been editing. If several people are in there, several people show. No artificial cap, and nothing that reads as gatekeeping, which fits how wikis work.
  • Does the article get disabled for everyone else: no. It stays a soft, informational signal ("recently edited by X"), not a lock. Someone can still choose to jump in, they're just doing it with eyes open. Hard-locking an article to one person would cut against wiki norms anyway.
  • Auto-unclaim vs manual: it takes care of itself. Because the signal comes from edit activity, it fades after a period of no edits. Nobody has to remember to release anything.

@JFernandez-WMF My lean is to build on the recent edit activity we already capture rather than try to detect live "editing right now" presence, which would be a much heavier lift. Does that tradeoff feel right from the design side?

thanks @OBenhmida! i see the benefit of reframing this away from 'claiming' since maybe we don't want it to feel like ownership/hard lock!

my concern is that 'recently edited by X' may not fully solve the original problem that we received from the feedback, IMO the issue seemed to be more about coordination before work happens (e.g. someone planning to create/improve an article and another person unknowingly starting the same work). recent edit activity only appears after someone has started editing

i wonder if there is a middle ground- avoid the language of 'claiming' but still allow participants to indicate intent with something like "I'm working on this". that could remain non-exclusive, allow multiple people, and not disable the article for others.

something like this is my thinking:

Group 9 (1).png (5,091×2,868 px, 2 MB)

Discussed with @JFernandez-WMF today: We need to decide whether to show only who is currently working on an article (from an active session) or also allow participants to claim an article they plan to work on later.

This card will be moved to a V3 of the worklist

since this will be moved to a later version I'm removing this task from Q1 board and moving back to backlog