Problem/Motivation

It's a pain to google for the contributor task docs, and copy and paste the url and write by hand a remaining tasks list... and then know what the needs tags are.

Proposed in https://portland2013.drupal.org/session/patch-reviews-get-good-reviews-g...
near the end: http://www.youtube.com/watch?&v=w4_McEbwVb8&t=19m10s

two pieces

providing a link to the contributor task doc when a tag *is* added.
and also
this is a combination of the idea of providing a curated list of common tags (the knowing what the needs tags are part).

mock up for providing link to contributor task doc (see others in #10)

interacting with curated list of common tags:

Maybe these should be separate.

See similar issues in dreditor for:

Proposed resolution

Use a computer to do that stuff.

Remaining tasks

User interface changes

Yes. checklist of remaining needs tasks.

API changes

TBD.

Comments

dww’s picture

Status: Active » Postponed (maintainer needs more info)

Sorry, but I don't have time to watch a DrupalCon session to figure out what you're talking about. Can you please explain better? Thanks! A picture might be worth 1000 words here -- can you do a (very primitive) mockup?

This sounds very d.o-specific to me, so this should probably move to the drupalorg queue, but I want to understand what you're proposing before I make that decision.

Also, without actually understanding what you're proposing, it seems like #1393226: Encourage use of issue summary template might get us most of the way there with relatively little work.

On the surface, this sounds to be quite complicated. Generally, I'm opposed to making the issue form any more overwhelming than it already is. If anything, I think we should be simplifying this form, not adding more fields/UI elements.

Also, the d.o d7 upgrade is never going to happen if we keep adding "just one more feature" like this, so I'd strongly encourage this to be D7 material. But, ultimately it's not up to me (it's not really up to anyone, and Drieschick continue to not reply to the d.o governance issues). *shrug*. But, I vote to get this working via the D7 codebase, not D6. However, I still don't fully grok what you're talking about, and if it's basically just bueditor bling, won't affect the data (and therefore data migration) for issues, maybe it'd be okay in D6.

Thanks,
-Derek

YesCT’s picture

Status: Postponed (maintainer needs more info) » Active

The idea was that when a patch producer submitted a patch, there would be a checklist of things "needed"
[ ] needs accessibility review
[ ] needs manual testing
[ ] needs screenshots
...

Maybe when a review does a review sees different or smae list with stuff like:
[ ] needs tests
[ ] needs reroll
[ ] needs backport
...

a bunch of the needs tags from https://drupal.org/needs-tags

And then in the summary (or a new comment on the issue?) (appended to their comment?)
would be a list of whatever they checked off, and it would auto link to the right doc in https://drupal.org/new-contributors

So for example,
webchick or alexpott can go to review an issue marked rtbc,
they try and apply the patch, see it does not apply.

Right now, they add the tag needs reroll
what I want to have happen is that they check a box for needs reroll
and then automatically, it adds the tag needs reroll, and links to
https://drupal.org/patch/reroll

Or a patch producer uploads a patch and they need manual testing,
so right now they add the tag needs manual testing
what I want to have happen is that they check a box for needs manual testing
and then automatically, it adds the tag needs manual testing and links to
https://drupal.org/contributor-tasks/manual-testing

So I dont know about if this needs to be part of the issue summary or comments or ...
The main motivation is that the needs tags are great.
but the information about how to do the tasks is hidden.
Patch producers, reviews, committers... are too busy to be googling for
"contributor task accessibility review" to find the doc that would tell someone looking at the issue how to do an accessibility review.
Right now, people are doing pretty well with adding tags.
Adding tags is nice because it autocompletes and we are standardizing on tags that start with "needs...

dww’s picture

Project: Project issue tracking » Drupal.org customizations
Version: 7.x-2.x-dev » 7.x-3.x-dev
Component: Issues » User interface
Issue tags: +Needs usability review

Thanks for clarifying. That makes a bit more sense.

My thoughts:
- This is definitely a d.o-only customization, not something project_issue should be doing itself. Honestly, dreditor might be a better place for this.
- There's a big risk that the cure is worse than the disease. A whole bunch of additional checkboxes could be overwhelming for 95% of issue queue users.
- If this is going to be implemented, it needs a usability review.
- This is not urgent enough to do in D6. This should happen after the d.o D7 launch.

If you want to work on this in dreditor (which is totally independent of d.o development cycles) go for it.

Thanks,
-Derek

drumm’s picture

I built a dev site out for this as requested in #2013092: I want a drupal.org development site for my work on core and community strategy and process. http://issuetasks-drupal_7.redesign.devdrupal.org/ is the first Drupal.org D7 dev site buildout since devwww was rebuilt and it looks like it is working okay.

YesCT’s picture

Thanks! :)

YesCT’s picture

An alternative is that when a tag is added,
a link to the contrib task doc is appended to the comment. That's a good match for dreditor I think.
The downside of that, is that people have to know about tags, and what they are. Compared to a checklist which would expose that community information.

YesCT’s picture

background info that might help discussion: tags and contributor task page pairs

From https://drupal.org/needs-tags

Needs accessibility review https://drupal.org/contributor-tasks/accessibility-review
Needs backport to D6 https://drupal.org/contributor-tasks/backport
Needs backport to D7 https://drupal.org/contributor-tasks/backport
Needs change notification https://drupal.org/contributor-tasks/draft-change-notification
Needs committer feedback
Needs documentation
Needs issue summary update https://drupal.org/contributor-tasks/write-issue-summary
Needs manual testing https://drupal.org/contributor-tasks/manual-testing
Needs profiling
Needs screenshot https://drupal.org/contributor-tasks/add-screenshots
Needs tests https://drupal.org/contributor-tasks/write-tests
Needs usability review

Other needs tags not in that doc:

Needs architectural review
Needs config schema
Needs followup
needs JavaScript review
Needs remaining tasks
Needs reroll http://drupal.org/patch/reroll
Needs steps to reproduce https://drupal.org/contributor-tasks/add-steps-to-reproduce
Needs security review
Needs upgrade path
Needs upgrade path tests

Status which could link also:

Needs review https://drupal.org/contributor-tasks/review
Needs work https://drupal.org/contributor-tasks/create-patch
Active https://drupal.org/contributor-tasks/create-patch

(Active is: needs discussion and/or needs initial patch, and needs work is not *just* create a patch...)

tasks documents without tags in use

https://drupal.org/contributor-tasks/document-mobile-cms-interfaces
https://drupal.org/contributor-tasks/edit-documentation-page
https://drupal.org/contributor-tasks/fix-page-titles
https://drupal.org/contributor-tasks/improve-patch-standards
https://drupal.org/contributor-tasks/incorporate-comments
https://drupal.org/contributor-tasks/retest
https://drupal.org/contributor-tasks/support-requests
https://drupal.org/contributor-tasks/triage
https://drupal.org/contributor-tasks/translate

---------------
See also: http://drupalmentoring.org/task-info

YesCT’s picture

d.o would be super... but did some dreditor thinking so posting that for now here.

If someone with dreditor is the one to add the tag, then adding the task document to their comment or a new comment has the benefit of anyone who does not have dreditor would see the contributor task document. But if someone without dreditor adds the tag, then no contributor task doc on the issue for that tag. And, if the tag gets removed and added back, the link to the task gets added (as part of a comment) over and over each time.

If dreditor were to just show the contributor tasks for tags already on the issue, then even if a person without dreditor adds a tag, others can see the task doc... but only if those others have dreditor.

a screenshot and sample html of playing with what dreditor might be able to do is on https://github.com/dreditor/dreditor/issues/16#issuecomment-24633410

ianthomas_uk’s picture

While I’m a big fan of making this documentation easier to discover, I don’t think the joelpittett’s mockup does this in a particularly clear way, mainly because the reason the links are showing isn’t immediately obvious on your first visit.

I think there needs to be a stronger link to the tags, and would actually replace the tags field with this new content. The simplest way to do this would be to add a link such as ‘more info’ next to each tag.

Issue tags: Needs backport to D7 (more info), Needs issue summary update (more info), Needs steps to reproduce (more info), Needs tests (more info), PostgreSQL (more info).

Here I’ve chosen a deliberately vague term so it can be used on ALL tags. On some tags it might give detailed documentation about how a user can help resolve the tag, others might link to an initiative’s microsite (focus) or in the simpliest case it would just link to a definition of the tag.

An alternative, even easier for noobs but a bit confusing for intermediate users, would be to pull the ‘Needs…’ tags out of the tag pool into a “What needs doing?” section. To work well, this sort of solution might need to be implemented on drupal.org rather than Dreditor (e.g. by having a separate field to replace the ‘needs’ tags).

Regarding the mapping of links to comments, this is content and isn’t really something that should be shipped as part of a release of Dreditor, could these be managed somewhere else? Maybe redirects could be configured at a standard location on drupal.org and Dreditor would always link to that? E.g. for needs change notification, Dreditor would send the user to https://drupal.org/issue-tags/needs-change-notification which would forward to https://drupal.org/contributor-tasks/draft-change-notification. A disadvantage of this is links couldn’t have customisable text or visibility (is there a valid case where a link wouldn’t be useful, or does that just suggest there is missing documentation?).

YesCT’s picture

Variations:

A) remove duplication of tags, and just integrate with the needs tags.
put the needs tags (linked to advanced d.o search) first, then the docs.

tags-and-needs-tags.png
source: https://drupal.org/files/dreditor-notags.txt

B) more, to be used for contributor task docs, or other links, like to an initiative or something.

more-links.png
source: https://drupal.org/files/dreditor-more.txt

C) separate out the needs tags. know that they are different than topical tags.
crazy talk: be able to assign each task separately

We used to think that working on an issue (that has status: needs work) was: make a new patch, and we use the assigned field to help prevent two people from doing the same thing and duplicating effort. Now, we know that there are more "tasks" that make up an issue. people are confused by assigned... I think having the assigned inline with the needs tag would be nice.

assigned-crazy-talk.png
source: https://drupal.org/files/assigned-crazy-talk.txt

ianthomas_uk’s picture

Is there any significance that A is missing the D8MI tag?

C has dropped the existing status and assigned fields entirely in favour of moving this functionality to tags. That would be a huge change across the application, most obviously search forms and results wouldn't have a single value field to act on so their interfaces get more complicated. There probably are some useful ideas around multiple assignment, but I'm worried that if we start exploring those then it will just delay the improvements to tagging.

Regarding A vs B I think B is a lot easier to read, as you can scan vertically down and ignore the (more) link until you need it. However, as a new user what would you expect to happen when you click on, say 'needs backport to D7'? I'd be tempted to move that to a separate link too, so you had:

* Needs backport to d7 (similar issues | more info)

Note I've also gone back to 'more info' rather than just 'more', as more could mean more issues or on an issue with a single tag it could be taken to mean more tags.

YesCT’s picture

Issue summary: View changes

identifying two parts of the issue and linking to the dreditor issues with have mock ups

YesCT’s picture

Issue summary: View changes

embedding mockups in issue summary

YesCT’s picture

Issue summary: View changes
FileSize
1.61 MB

html, right image links, new remaining tasks.

tvn’s picture

Is the dev site http://issuetasks-drupal_7.redesign.devdrupal.org/ needed right now? Last access was on October 14. If it isn't actively used at the moment, we could use that space for another dev site and rebuild later when you need it.

tvn’s picture

Confirmed with YesCT in IRC and deleting the dev site for now.

xjm’s picture

Assigned: Unassigned » xjm

Emboldened by #2151041: Add a "draft" status for change records, I'm going to take a stab at an initial patch. I'll use the existing dev site at http://project-issues-drupal.redesign.devdrupal.org for now.

xjm’s picture

Title: Add checkbox list of tasks an issue needs that links to contributor task docs and adds the cooresponding needs tags » Add "issue tasks" metadata to core issues and integrate with handbook documentation

Retitling to reflect the goal rather than a particular implementation. :)

xjm’s picture

Alright, here we go. I did the minimum necessary to implement the feature in a way that was consistent with the existing issue queue functionality.

Implemented in the patch

  • An issue_tasks vocabulary to provide a managed list of issue tasks (separate from the free-for-all issue tags field).

  • A node reference field on the issue_tasks bundle to reference a handbook page with documentation for the task. This can be used to build site features linking documentation for the task.

  • A proposed set of task terms based on YesCT's post in #7. (We might want to refine this list; see below.)

  • An update hook to create the starting list of task terms and add them to existing nodes with the corresponding "Needs" tags. (I did a lot of refactoring on this to minimize the number of queries it runs.)

  • Issue node display configuration and styling for the issue tasks. (The separate patch against bluecheese adds CSS to make the tasks display like tags. Rolled with diff.)

Remaining tasks

  1. Feedback needed on the proposed architecture and the implementation.

  2. Issue node revision comment integration thingy. When you add a task to a node it looks like this:

    At a minimum there should be a "Tasks" line there that shows what tasks were added or removed. I haven't yet tracked down how this is implemented. What would be even better, though, would be inserting the link to the task handbook page right there in the revision comment.

  3. Issue queue view integration. My idea for the first iteration was to add the most minimal, nondisruptive integration possible for the handbook links and queue by simply adding the field to the advanced search criteria, linking the field in the sidebar to the advanced search view just like tags are, and then adding a small help block linking the documentation for the task. Here's a mockup of what that might look like, if you clicked on the "Change record" link in the node sidebar:

    I thought I knew what I was doing and tried to add the field to the Search API views. Hilarity ensued. First I tried to add the tasks vocab to the search index like the tags vocab:

    So far so good. Then I went to add it to the issue search view. It seemed to work except for this weird thing where none of the task terms were listed in the view filter configuration:

    Saved the view like that anyway. But it's the same broken on the view itself:

    I thought maybe the index needed to be updated or something for the terms to show up, so I tried that. But it got stuck on a record 10% in and could never complete, no matter how many hours I gave it:

    So I gave up on that for now. I can work on that once I get some feedback on the initial patch and maybe some help from project_issue gurus. :)

  4. There's also some bug with the google admanager something something that displays a notice on the issue nodes. The "undefined index" referenced is the serial ID of the issue tasks vocabulary:

    I haven't tried to debug that yet either.

  5. Eventually, I'd like to have a nice "Find a task" view that contributors could use to find tasks to work on, with docs referenced and suchlike, with a toggle for filtering it to novice issues. That can go in a subsequent patch though. As can the brave future in which we add a tool for task mentoring and assignment. :)

  6. Let's discuss which tasks deserve being in the task list. Here's the list of tasks I added. We might not want all of them:

    • Accessibility review
    • Automated tests
    • Backport
    • Change record
    • Code review
    • Committer feedback
    • Create followup issue
    • Improve documentation
    • Improve patch standards
    • Issue summary update
    • JavaScript review
    • Manual testing
    • Profiling
    • Reroll
    • Screenshots
    • Security review
    • Steps to reproduce
    • Upgrade path
    • Upgrade path tests
    • Usability review

    Here's the tasks I excluded, and why:

    • Needs config schema: This is a very specific D8 task, and can remain an issue tag.

    • Needs remaining tasks: This tag seems silly to me. It's either simply part of an issue summary update, or something you should just do.

    • Tasks and documentation related to issue statuses. The statuses are just too broad, with too much variety in meaning, to magically link one handbook doc for them.

      However, I did add a task specifically for code review, which we distinguish from other kinds of review like manual testing. A "code review" task is usually (but not always) implicit from a NR patch, but making it explicit helps both reviewers and patch authors. If the community adopts it, it could also be a valuable way to discourage drive-by dreditors on patches that are intended for architectural feedback only.

    • The tasks described in the following docs are all outside the scope of the issue queue:
      https://drupal.org/contributor-tasks/document-mobile-cms-interfaces
      https://drupal.org/contributor-tasks/edit-documentation-page
      https://drupal.org/contributor-tasks/fix-page-titles
      https://drupal.org/contributor-tasks/incorporate-comments
      https://drupal.org/contributor-tasks/translate

    • https://drupal.org/contributor-tasks/retest : Seems silly to have a task for this, since all it involves is clicking a link, which takes less time than it would to add a task tag.

    • https://drupal.org/contributor-tasks/triage : This one is a bit trickier, since it applies to new issues created by people who aren't as familiar with how to use the issue queue. A future implementation might have it automatically selected for newly-created issues... which would annoy experienced contributors who do 80% of issue creation... or the rainbow-unicorn implementation would do some sort of newfangled user analysis and select it for a certain subset of issues. The problem we have with triage in core mentoring is that you need to kind of pre-triage them so that novices don't postpone sun's issue asking for more information. (This happened.) So I've considered triage out of scope here.

    • https://drupal.org/contributor-tasks/support-requests : This is related to an issue category, not an issue task. We could add a separate way to link documentation for it, but I think it's out of scope here.

YesCT’s picture

in general. wow. super.

concern: the select box is small, can we do something to show all tasks once someone clicks into it?

--
people will still have the habit of adding needs tags, can we intercept specific tags people add, and then show a message: "needs reroll" is not a task, please select reroll in Issue tasks.

This will effect contrib also, right? We need to get a few new, and experienced maintainers of contrib modules to chime in here. I'm hoping the wish for a different set of tasks per queue is not a blocker.

thoughts. there are a few of these that are "review", but not listed is architectural.. or (big picture) are we just going to encourage people to say that in a comment when they change the status to needs review? will people want to list the issues where "architectural review" is needed? Will we use a tag for that?

xjm’s picture

concern: the select box is small, can we do something to show all tasks once someone clicks into it?

I deliberately used the default implementation to be consistent with other fields. A list of checkboxes would be giant. We could iterate on the UI for it, but I'd prefer to do that as a followup since it'd require design resources and frontend skills I don't have.

people will still have the habit of adding needs tags, can we intercept specific tags people add, and then show a message: "needs reroll" is not a task, please select reroll in Issue tasks.

I think that's inadvisable. We can delete the tags (either automatically or manually), and make a g.d.o/core post, and update our documentation, and re-educate people.

This will effect contrib also, right? We need to get a few new, and experienced maintainers of contrib modules to chime in here. I'm hoping the wish for a different set of tasks per queue is not a blocker.

I briefly considered implementing it for core only, but I think if we get the list right it will be generic enough to be beneficial to contrib. We could down the road implement per-project functionality, perhaps by adding another field to the issue_tasks bundle and filtering the list on that field, but I definitely don't want to block the initial patch on that. And TBH I'd prefer that it not be necessary.

thoughts. there are a few of these that are "review", but not listed is architectural.. or (big picture) are we just going to encourage people to say that in a comment when they change the status to needs review? will people want to list the issues where "architectural review" is needed? Will we use a tag for that?

Er, that's a bug. It used to be in there. I must've removed it accidentally. Will add it back in the next iteration.

Also, I spoke to @jthorson on IRC. He +1ed implementing this as a drupalorg feature rather than rolling it into project_issue.module. He said the node comment revision status update thingy is in the nodechanges module, and suggested I look in the apache logs when I next dare to screw around with the search api index. :)

Thanks both!

xjm’s picture

  1. +++ b/features/drupalorg_project_issue_tasks/drupalorg_project_issue_tasks.module
    @@ -0,0 +1,335 @@
    +
    ...
    +}
    ...
    +function foo() {
    ...
    +function drupalorg_project_issue_tasks_init() {
    +}
    

    lol. obvious debugging code that should be removed. :)

  2. +++ b/features/drupalorg_project_issue_tasks/drupalorg_project_issue_tasks.module
    @@ -0,0 +1,335 @@
    +function _drupalorg_project_issue_tasks_terms_with_tag() {
    ...
    +function _drupalorg_project_issue_tasks_terms_no_tag() {
    

    These two can probably live in the .install; I had them in the .module for debugging.

dww’s picture

Hurray for an amazing job writing up what you've done and how! I sadly can't tear into this in depth right now. I'll try to look more closely later...

However, I have some meta concerns about plowing ahead with this:

A) This (might) all make good sense for core, but seems totally overwhelming and overkill for most issue queues on this site. Do you intend to restrict this to only impacting core issues? If so, how? If not, why not? ;)

B) The UI on issues is already complex and broken. There's a lot of work going into trying to improve (and in some ways, simplify) the experience. This seems like a step in the other direction. Send more fields and form elements! Yikes.

C) There's all this talk (as you're probably aware) of Developer tools team leadership. These seem like pretty big changes to be making, and even if I was whole-heartedly on board with them (which I'm not) I'm not sure how this should proceed. Personally, I think it'd be wise to postpone this and not spend much more time on the details until there's more progress on Drupal.org development process 2.0 and friends. I just fear you're going to invest a lot of effort clicking this together on a dev site that's going to bitrot before anyone can meaningfully decide if/how to actually move this forward.

That said, if you want to keep going... ;)

Re: remaining task #2: That's all via Nodechanges module, and if/how changes are displayed is handled via the Node changes output view mode configuration when configuring the display of an (in our case, the) issue bundle. Pretty similar to how the stuff in the sidebar is controlled via the Project issue meta data table view mode. Anyway, since it's just fields and a view mode, you can control the presence, order, and formatting for any field you want displayed in those tables of what fields changed for a given node revision.

If you want the terms to link to handbook pages, you could either write a custom field formatter that renders these terms as links, or you could write your own URI callback for terms (see project_issue_taxonomy_term_uri() and be sure to invoke that in the else case where it's not the vocabulary you care about) to link to these whenever a term is formatted to render as a link to itself. However, sometimes you might want these terms to link to issue queue views restricted to the tasks you care about, so maybe do both and pick the right formatter in the right case. ;) Left as an exercise for the interested reader...

Anyway, I'm really excited you're diving in to make improvements like this, and I don't want to stifle that, but we're still in a very grey area where the historic/informal "D.o team" is still doing things in the historic/informal way, and we're still drowning in d.o D7 upgrade bugs. :/ So, part of me feels responsible to say: "thanks, but hold your horses for the moment..." :/

Thanks/sorry,
-Derek

xjm’s picture

Issue tags: +Core mentoring on d.o
xjm’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

@dww and I discussed this on IRC but I failed to come back and document the discussion afterward. :) Marking NW until that update is here and it's easier to review the proposal (and, well, there are outstanding tasks that should be done before further review anyway). :)

xjm’s picture

mgifford’s picture

I just created this issue, but agree with @drumm that it's probably a duplicate #2211543: What's the current issue status?

I was trying to capture ideas from https://groups.drupal.org/node/134489 in the issue queue so they didn't get lost in GDO.

YesCT’s picture

a work around is an issue summary template for novice issues (WIP)
https://docs.google.com/document/d/1xnL18eC2Cwo2YnB0PwmBnn86Eo8aF9CF4qDL...
(also see irc factoid: novice issue summary?)

markcarver’s picture

Title: Add "issue tasks" metadata to core issues and integrate with handbook documentation » Add "Issue tasks" to project issues and correlate tasks with handbook documentation

I really think this should be for all projects, not just core. I think we should approach this how we do issue components, in the sense that each project is given "default" values and can then customize to the project's needs. Core obviously has it's own tasks, but a lot of these tasks could be generalized as "best practice" for all projects really.

I think this would also be extremely beneficial if people were to start seeing this on a contrib level. Quality of issues in general I think would increase because people could see what needs to happen next. Also, this could help potentially soften the blow of what "issue tasks" are when an individual starts working in core issues. They would likely already be familiar with them in contrib issues.

YesCT’s picture

YesCT’s picture

Issue summary: View changes

adding notes from #nyccamp
http://bit.ly/how-to-pick-an-issue-feedback
and related video https://www.youtube.com/watch?v=jnKZM30q6fQ

and added to the issue summary, a link to a simple d.o issue to try before jumping into this complex one. :)

xjm’s picture

YesCT’s picture

Assigned: xjm » Unassigned

#2362065: Sort autocomplete of issue tags descending by usage count *in the issue metadata form* will help float up the most relevant tags.

(and I think we are (ideally) moving in a direction of not depending on tags anyway)

Bojhan’s picture

Issue tags: -Needs usability review
YesCT’s picture

YesCT’s picture

YesCT’s picture

YesCT’s picture

trying to find all the issues which depend on d.o being able to display context sensitive messages. tagging.

xjm’s picture