edit tags / update tags button

[YesCT]

pencil mock up of editing tags on an issue.

Idea: a) make it easier to tags when a needs.. task is done, or just remove irrelevant tags by showing current tags on top, as button-like things with an x to remove them, or in a checkbox list, and unchecking them to remove the tags. b) under the current tags, show a curated list of commonly used tags like: needs reroll, needs issue summary update, etc.

curated list to be maintained in a dreditor issue, based also on https://drupal.org/needs-tags

Why? because the autocomplete drop-down only lists 10 items, alphabetcally, and thus sometimes the one people should be adding is hidden.

Still allow, new tags to be added in the autocomplete for people who know what tags they want added.

---

https://github.com/dreditor/dreditor/issues/32 save personalized most used.

---

Separate issues that can build on this later:

1) For needs tags that have a corresponding contributor task document, add a link to instructions on how to do the task to the end of the comment. This allows the author of the comment to remove the instructions if they do not want them in their comment.

2) Have user stored settings to allow them to customize their own list of common tags.

Related "edit tags / update tags button" https://github.com/dreditor/dreditor/issues/16 "Add checkbox list of tasks an issue needs that links to contributor task docs and adds the cooresponding needs tags" https://drupal.org/node/2013222

[YesCT]

A google doc spreadsheet of needs tags and contributor task document pairs. https://docs.google.com/spreadsheet/ccc?key=0AtDYnjV5l0uydDJ5dU1WZ1ZFQ1lSX19PTEh0eWRsR0E&usp=drive_web#gid=0

[sun]

I never got around to do this, but I always wanted to overload and replace the d.o native issue tags widget with jQuery TokenInput (lightweight, bullet-proof, jQuery) or Chosen (larger, JavaScript). In any case, that UI widget should not be re-invented; these libraries are excellent.

Instead of hard-coding or fetching any kind of default list of tags, my plan was to leverage localStorage to build a user and usage specific and ranked list of most often used tags that are exposed on demand - without typing any letter. Every tag autocompletion adds to that list, but over time, only tags with a minimum usage threshold are remembered.

That has the benefit of working for more than Drupal core. In general, I'd like everyone to bear in mind that contributed projects have different needs and do not necessarily follow the procedures that happen to exist in core. Dreditor strives to be a solution for all contributors and project maintainers.

In short, Dreditor should adapt to your personal usage, and not enforce something that doesn't make sense for your use-case.

[YesCT]

sun, I agree. Contrib needs are different, and having something that learns each person's most used tags would be excellent.

Seeding that list would be good... we can know if an issue is in the core project and have a core seed set. I wonder if there is a good guess at a contrib set.

Does this relate to personalized settings in general? Where is that issue about local personal settings.

[clemens-tolboom]

This comes close to my effort for having state transitions and stock responses.

Issue https://drupal.org/node/1115636 Book pages: https://drupal.org/node/1120672 Sandbox: https://drupal.org/sandbox/clemenstolboom/1125712 A UX by @bojhan: https://drupal.org/comment/5589422

It's not personal but project based as the configs are on d.o

[markhalliwell]

Dreditor is being decommissioned due to the lack of availability of current maintainers and the fact that Drupal.org is becoming more feature rich at a much faster rate than Dreditor itself now.

This decision was also partially made due to the amount of work (complete rewrite) it would take to create an "official" Firefox extension (#256).

If you already have the extension installed, it should continue working for a while until, inevitably, the markup on Drupal.org changes. It will no longer be updated.

We understand that many of you love this extension, as do we. This isn't the end, in fact, it's a much brighter beginning. All the things we love about Dreditor can, and should, be moved into Drupal.org natively.

For more information, please follow: https://www.drupal.org/node/2779729

[subhojit777]

This issue was moved to dreditor/dreditor#47