Updated: Comment #N

Problem/Motivation

When an issue has a lot of comments, it takes considerable effort to find out who has been the most involved and who might have the most knowledge about the issue.

Proposed resolution

Add a list of commenters' usernames to the issue page with the number of their comments, ordered descending by the comment number. The number of uploaded patches and the number of status changes could be interesting too, but then it should rather be a table instead of a simple list.

Possibilities:
1) use a view or sql query to generate the data
- would this slow the page load? if so, I think we should not.
2) use javascript to get the info that is already on the page

Remaining tasks

User interface changes

The list should take place in the sidebar below the "Jump to" menu, and it should be collapsed by default to avoid clutter.

API changes

None.

Related Issues

CommentFileSizeAuthor
#15 out.tsv_.gz228.72 KBdrumm
#6 team.png409.9 KBYesCT
#4 names.txt1.71 KBYesCT
#4 blockwstats.txt2.81 KBYesCT
#4 justnames.png306.98 KBYesCT
#4 peoplestats.png174.77 KBYesCT
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

Issue summary: View changes

add related dreditor issue

markhalliwell’s picture

A simple list of the number of comments wouldn't be that hard to implement.

However, I must argue that has little to no context as to the value of the comments.

It'd be interesting if we could add the string length (minus entire code blocks and html markup) could play into this? For example:

User A adds 3 comments, each a few paragraphs long.
User B adds 15 comments, each a single sentence (sometimes to explain their status changes or a simple yes/no to questions).
User C adds 1 comment, a novel really. They spent a lot of time thinking about the issue and/or have valuable insight to the issue at hand.

Which user really has "knowledge" about the issue? Relying on a list that simply uses "# of comments" isn't very reliable IMO.

csg’s picture

There is no perfect method for this, but one long comment means you have spent time thinking on the issue only once, while a lot of short comments means you have been following the issue's progress for a while. I still think it is a better indicator.

YesCT’s picture

FileSize
174.77 KB
306.98 KB
2.81 KB
1.71 KB

txt files are html that can just be inserted into an issue page.
But, I think it might actually be easier to mock this up using dreditor and javascript.. but here are two terrible starts.

Based on this little trial, a table is probably best, if the data could be in there, and js could sort it client side.

people with stats

(let me be the first to say: ick, and sortable table would be better)

just people

The simple version.
(I think this might work better styled to be a comma separated list that runs all together and not each on its own line.)

---
And I think both should be collapsed by default (but I didn't make them that way)

markhalliwell’s picture

Just some notes (to keep track here):

  • I like the named list better (cleaner, on separate lines). I was thinking the weight/sort would be more transparent (automatic). I would imagine clicking their name would take me to their most recent comment. Also, when #957320: Enable the support for user profile pictures lands, I could see displaying this along with their name here.
  • I don't think it should be collapsed by default. The only thing that really has "collapsibility" is the forms. This is useful information and should remain visible.
  • Limit (and rename title) to maybe "Top 10 Participants". This for knowing who has the most knowledge of an issue... not everyone who has participated. Is there any real reason why knowing everyone who has ever commented is necessary? If it is, could this be what is collapsed below the top 10 as "All participants"?
  • "System message" user will need to be filtered out.
YesCT’s picture

FileSize
409.9 KB

The collapsed by default was a way to encourage this to not be a leader board, or have people game this.

For similar (social/political) reasons, I would not be comfortable limiting it to Top X Participants.

Practically, though, I dont just want to know who is knowlegable... I want to know who is interested *at all*. Someone who comments once, might be an untapped resource, and we might be able to encourage them, and point them to other places they could help with.

A person who is commenting 20 times on an issue, is probably pretty busy. Someone who comments once... might have some time open to take on another issue.

We do not exclude people who commented 3 or few times from the d8mi team ...

---
Summary: some people might find this useful to identify people knowledgable in an issue or area, some people might use it to identify people with untapped potential, and others might use this in ways we haven't thought of yet.

So I think we should include everyone.

YesCT’s picture

I think clicking on their name and having it go to their most recent comment is a sane thing to do.

The other idea I had, was that it would hide comments by others, and only show comments by that person... but that might be weird.

YesCT’s picture

Issue summary: View changes

from irc, markcarver commented:

a decision needs to be made of what data is actually desired. If it's a table metic, we should probably add that meta as the parent

I think that was in support of the data coming from a query, but I'm not sure.

Bojhan’s picture

I am quite unsure about the added value of this, we already have a lot of information in the sidebars. I am not sure about filling it up with this.

drumm’s picture

This should also be tested with smaller issues. Most issues do not have a huge list of commenters. We shouldn't over-optimize for huge issues.

YesCT’s picture

Do we have data? For closed (fixed) issues, do we know how many people commented? average, median.

YesCT’s picture

@Bojhan Yeah, that is why I was thinking it could be collapsed.
An alternative could be to put it (still collapsed) at the end of the issue.

@drumm This could be a very good one to try out in dreditor first to get a feel for if it is useful and how it is useful.

YesCT’s picture

YesCT’s picture

Issue summary: View changes

link in summary to how to do things on d.o

drumm’s picture

FileSize
228.72 KB

Some data on Closed (fixed) issues:

mysql> SELECT q.core, count(1) AS issues, avg(commentors) FROM (SELECT (fp.field_project_target_id = 3060) AS core, count(DISTINCT uid) AS commentors FROM field_data_field_issue_status fis INNER JOIN field_data_field_project fp ON fp.entity_id = fis.entity_id INNER JOIN comment c ON c.nid = fis.entity_id WHERE fis.field_issue_status_value = 7 GROUP BY c.nid ORDER BY NULL) q GROUP BY q.core ORDER BY NULL;
+------+--------+-----------------+
| core | issues | avg(commentors) |
+------+--------+-----------------+
|    1 |  27935 |          5.8970 |
|    0 | 336321 |          3.2350 |
+------+--------+-----------------+

Median doesn't seem straightforward in SQL, so the results of the inner query are attached.

(In general, dev sites are good for designing/writing queries, so anyone with staging access can run the queries on staging/production with a full data set, and not need to think about writing the SQL. https://drupal.org/node/1018084)

YesCT’s picture

Status: Active » Closed (duplicate)
Related issues: +#2295411: Auto-generate Git attribution info / commit messages on Drupal.org

This is kind of "done" with the new credit UI that is exposed to all people. #2295411: Auto-generate Git attribution info / commit messages on Drupal.org

Do we want to keep it open for something else we show on the actual page and not part as a form (that is in a field that most people might keep collapsed)?

YesCT’s picture