"Assigned" field is confusing and not appropriate in all circumstances [#2143083]

This is *not* a regression because of the upgrade. Maybe this belongs in a different issue queue

Updated: Comment #N

Problem/Motivation

There are no instructions for how to use the assigned field.
People who have been around for a while know the traditions involved with assigned.
People assign an issue to themselves, then come back to post the result, and find someone has posted a patch, and then they are heart crushed and cry and dont want to contribute anymore.
people assign an issue to themselves, then forget or get busy and don't mind if someone else posts a patch
people assign an issue to themselves when they *post* a patch, not when they *start* working on a patch
people assign an issue to themselves for a task that is *not* making a patch like: testing, or updating an issue summary

The use of this field is inconsistent and can lead to hurt feelings or confusion.

Proposed resolution

Expose how we use assigned better.
A) with documentation (but people probably wont read it) https://www.drupal.org/node/2172049 is the assigned field handbook page.
By putting a question mark next to the field and linking to docs that explain this hidden community knowledge.

B) with a different label
Suggestion: Assigned (currently working on a patch):
By making the label mean what we use it for, people dont have to click on something to go to another page to read docs (which they wont do).

C) Now that we understand there are more "tasks" in an issue than just making a patch, the Assigned field may not be appropriate anymore.
By having an assigned field for each remaining task (we can assume possible tasks based on a curated "needs ..." kind of list of things issues commonly need. Or different fields we hard code based on the core gates. (See #2013222-10: Add "Issue tasks" to project issues and correlate tasks with handbook documentation)

Remaining tasks

discuss (really, it's ok to say what you think)

User interface changes

API changes

No.

Comments

Comment #1

yesct commented 24 November 2013 at 14:47

Issue summary:

View changes

ack. just html fix in the summary.

Comment #2

star-szr

he/him

English

commented 24 November 2013 at 15:43

Issue summary:

View changes

Minor typo fix to the issue summary.

I like this idea because I agree it's hard to learn as is (and arguably harder now that it's an extra click away, not even visible on the issue page).

Comment #3

eliza411 commented 24 November 2013 at 19:38

+1 to exploring how to make communication via the issue queue more effective, which I think this is a piece of. My observation working on projects that span 10 to 20 queues is that there isn't a one-size-fits-all way to use the assigned field, especially with the settings we have now. I've mostly had to learn how different participants (not projects) use the field and work with it accordingly to either know what people are doing or how to get their attention.

I really miss two concepts:
* the idea that a reported problem has been verified as repeatable
* request for comment - there's nothing about the words Needs review that makes it code-centric, for example, and there are lots of things that need review/feedback/discussion that don't involve attaching patches

Assigned fields for a project's particular gates is intriguing.

Comment #4

xjm

she/her

English

commented 17 December 2013 at 19:05

Title:	"Assigned" field is confusing and maybe not appropriate anymore	» "Assigned" field is confusing and not appropriate in all circumstances
Priority:	Minor	» Normal
Issue tags:		+core mentoring on drupal.org

I am not sure I'd call the assigned field inappropriate--it is still heavily used in the core queue. But, our social rules around when to use it and when not to are definitely a barrier, and it also differs from project to project to be sure.

#2013222: Add "Issue tasks" to project issues and correlate tasks with handbook documentation explores the idea of breaking the tight coupling between "Needs review" and code review, btw.