Remove issue creation links from project pages

Big +1 from me, we should really encourage users to review existing issues before posting new ones, and the best way is showing them the queue first

Yeah, I've been thinking the same thing myself for a while, but I guess I never fixed it nor made an issue about it. ;)

Ultimately, it'd be nice if those links were more flexible from project nodes, so sites could more easily customize them to taste.

However, I think as a general rule, if people are viewing a project page anywhere (d.o or not) they should be encouraged to look at the issue queue before submitting a new issue. So, we should just change this directly in project.module itself. Patches for HEAD are welcome.

p.s. While we're at it, it's totally weird that the "view all issues" link lives down under "Development" while most of the rest live under "Support". This whole thing is wonky. See http://groups.drupal.org/node/6186 for some wireframes and lots of discussion about what the project node UI should be.

I never use anything but the "View all pending issues" link. Personally, I wouldn't mind seeing the whole "support" section there changed to something like:

To request support or file a bug report, please search the issue queue (link to issue queue there, preferably showing closed and dupes as well) first before creating a new issue. Make sure you give detailed information to help the maintainer help you. (maybe a link there to something about posting good bug reports).

Michelle

I'm not sure I agree on this change, and I don't feel that it should be done in a minor revision, considering that this is actually a pretty large change in how project nodes look.

In addition, I don't think it makes sense to put "View all issues" under support instead of development. Considering that 3 of the 4 types of issues (bug reports, feature requests, and tasks) are more development centric rather than support centric, I think it makes the most sense to leave it where it is now.

Perhaps these changes can be made from the drupal.org module?

I'm not opposed to making these changes for the D6 version (thought I'm still not wild about moving "View all issues"), but given that our next project release was supposed to be bug fixes, making this rather large change and calling it a "bug fix" is, IMO, wrong.

Since so many people post issues in completely the wrong category anyway, I think having all issue links together makes sense. I guess it's up to dww and aclight as to where the changes are made for D5, but IMO it's a great improvement.

I'm -1 on this:

# View pending issues [regular queue]
# View all issues [including closed]
# View all support requests [unchanged]

What does unchanged mean? I don't like having "including closed" as one of the easiest options. Just think of how difficult it will be to wade through certain queues if all closed issues are showing up as well. Keep in mind that right now, searching/filtering of issues is not wonderful. It's possible to search for multiple terms, but not a phrase, and boolean logic can't be used (as far as I recall). Search can be pretty slow at times as well. My guess is that people who attempt to search for an issue are willing to look through 1-2 pages of issues before deciding there is not a current issue for a problem. Showing more issues earlier on (eg. closed issues, or all issues instead of a specific type) will sometimes increase the chance that a user will see that an issue already exists for a problem, but will also sometimes decrease this chance.

I wouldn't disagree that all the links to the issue queues should be under the same heading, instead of some under "Development" and some under "Support", but I think this would require more reorganization of how project nodes look than I think is appropriate at this time.

I don't recall offhand, but how easy is it for an external module or theme function to override how these items are listed on the project node? If that's possible already (I think it is, since we added in a hook not too long ago to make it possible to have the "Report a security issue" link visible for project on d.o via the drupal.org module), then I think work needs to go into a patch to the drupal.org module that changes/rearranges/etc. these different links to be most appropriate for drupal.org.

Then, while working on the D6 port, things can be improved more and refactored and such for the longer term.

I think your comparison to the google code tracker is not the best. There's not really even a place to create a support request in google's tracker, and google's searching and filtering capabilities are much faster and more extensive than what our own issue tracker can do right now.

If you don't want to include closed, can you at least include dupes? I have one issue that has been fixed and closed for a while and there are about 10 dupes filed on it. The excuse? "The issue queue doesn't show me duplicate issues". So people that actually take the time to look at the issue queue aren't seeing that there are already 11 issues on the same thing already because the default view doesn't show them and they don't realize that.

Michelle

@Michelle: If the issue is fixed and closed, why are people filing duplicate issues still? Is it a feature you added to a new version but didn't backport, and people are filing requests for the older version? Including duplicate issues (or issues in any status) in the default view of issues is a site wide setting, so there is no need for a patch to do this.

It's fixed in the dev but getting another alpha release out has taken a while. So I've been getting report after report on it even though it's long been fixed.

I'm headed out of town so can't comment any more on this issue for a couple of days. But anything that will make people find existing issues before filing easier gets a +1000 from me. Dupes waste everyone's time.

Michelle

This is a hard balance to strike. A few things I think we could all agree on:

A) Duplicate issues are a huge waste of time.

B) Encouraging people to at least look at (if not actually search) the issue queue before submitting new issues is a good thing, d.o or not.

C) The project node UI is currently a mess. There was a big discussion about it on g.d.o and there are lots of things we could do to improve it. A huge refactoring of the project node UI is certainly out of the question for one of the final releases of project.module for D5. (That said, I'm not as opposed to making any changes at all as it seems aclight is).

D) If/when you land on "advanced search" all issue status values should be selected by default, not just the currently-configured "default query status" setting's values. Most of the time when I'm advanced searching, I do this, anyway, and it should probably just be the default behavior to encourage people to find closed/dup issues.

I don't think we'll ever agree on what status values the default queries should be since what maintainers should see is somewhat different from what end-users should see. I don't think it's the end of the world to present end-users with all the issues by default. They can always refine the query on the really busy queues if they need to, and they'd probably be happy to see all the activity at first (especially if they clicked on a link about "all" issues). That's why I like all == all, and pending == the default "open" issues query. But, there's no way (currently) to have different default status queries depending on your "role" within a project. Maybe #138056: provide a way to save issue queries into a "my favories" sort of thing should be factored into the considerations here.

Oh, and to answer aclight: yes -- hook_project_page_link_alter() exists. I forget exactly how much flexibility it provides, but someone could play with it a bit and extend the implementation in drupalorg.module if we can't come to an agreement for project.module itself.

I just looked closely at where project.module invokes this hook. Seems pretty cool:

    project_page_link_alter($node, $all_links);

    // Format links in $all_links for display in the project_project node.
    foreach ($all_links as $section => $values) {
      // Only add the section if there are links for the section.
      if (!empty($values['links'])) {
        $node->content[$section] = array(
          '#value' => theme('item_list', $values['links'], $values['name']),
          '#weight' => !empty($values['weight']) ? $values['weight'] : 0,
        );
      }
    }

That means we should be able to completely rearrange the links, add/remove sections, etc. Yay. ;)

So, we can go pretty crazy with this via drupalorg.module for now, and then harvest the best ideas for project.module itself in D6 by default. I still think some of the easy stuff could go in to D5 now, but I also don't want to piss off aclight, so if he's still in big -1 land, I'm happy to go along with him. ;)

FYI: #218571: add hook_project_page_link_alter(), implement to add security link to all project pages -- It's so nice to read an issue like that -- aclight, hunmonk and I all worked together to design the API for that hook in such a way that it's now the perfect solution to this problem. ;) /me feels all warm and fuzzy.

@dww re #14:
I won't be pissed off if you change the project node, but I think we'd need to discuss this in more detail before doing so, and I don't like the idea of making what I consider to be a fairly major change in the project node in a bug fix release. We could create a new 5.x branch, but I think that's going overboard as well.

Given that hook_project_page_link_alter() exists and, I believe, if implemented in the drupal.org module will give us exactly what we want for drupal.org, I think it's a better idea to fix it now on drupal.org, see how the response is, and use that knowledge to guide us when considering whether and how the project nodes should be changed for D6 project*. I'll be the first to admit that I don't love project nodes right now, but I just don't think the proposed change is the right route to take for project* as a whole.

Ok, it's clear that for now, we're talking about a drupalorg.module customization via a patch to drupalorg_project_page_link_alter() to "stop the bleeding" on d.o itself. I'm fine with being cautious for changes to the upstream project code itself in D5. So, the above patch needs to be re-written.

#14.D should just move into a new issue since it's related but totally separate code: #310874: Select all issue status values by default for advanced search.

A brief glance at the code looks good, but I haven't tested it.

I wonder if instead of having "All pending issues" we should instead make this "All open issues".

I like "open" instead of "pending", too.

Another +1 for 'open', that's much, much better.

A) Because it's a change to d.o and I never take that lightly. We need to test this before I just commit and deploy it.

B) Because I'm busy, I have a life, and it's the weekend. We've lived with project nodes like this for 4+ years, you can wait another few days if necessary. ;)

"What holds this patch off from being applied?"

C) Because it doesn't work. ;) I applied it on project.d.o and it's broken. See http://project.drupal.org/project/signup for example.

No time to debug and fix it now, so feel free to reroll yourself. Also, I recommend setting up a project* test site using the http://drupal.org/project/drupalorg_testing install profile. Detailed instructions here: http://drupal.org/node/199369 -- if you did that, you could test this yourself and it'd be much more efficient for everyone involved.

Thanks,
-Derek

Thanks. Reviewed and that code looks much better. Deployed on p.d.o, and it seems mostly great.

My only lingering concern in the scope of this issue is why we give anonymous users the "Login or register to create an issue" stuff directly on the project page, when that sets the destination to node/add/project-issue/[project-name], seemingly to bypass the point of this effort. They get that at the top of any of the issue query pages they land on, which seems more in line with the intentions here. So, I rerolled the patch to take that out, too.

At the risk of feature creep, I also added a direct link to "Search issues" after the various 'view' links.

Committed to CVS and deployed on d.o.

p.s. @aclight: Mind if I commit that "Search issues" link directly to project_issue? I can't possibly imagine a use-case where that would be unwelcome by default. ;)

Awesome, thanks, dww! I got my 12th dupe on the exact same issue that's been fixed for some time this morning and I'm hoping that will be the last. LOL

Michelle

@dww: re: #30: That's fine with me. Minor question--with most of the issue links now pointing to all issues (at least those under the support heading), should the new search issues link also search issues of all status, not just the default ones? I wouldn't want this for pi in general, but maybe for d.o that would be desired.

@aclight: Ok, committed the 'Search issues' link to to HEAD and DRUPAL-5, backed out that change from drupalorg.module, and deployed everything on d.o. And yeah, let's just talk about that advanced search issue over at #310874. Thanks.

Bopping over from the dev mailing list. Overall I think this is a fantastic change, but I worry about inexperienced users tearing their hair out before they find the "Create" link.
How about changing the link from "View open issues", to "View open issues (start here to report new issue)".
And then changing the "Create" link to "Create New Issue", so it is a little more eye catching.

(not feeling bold enough to move the status from fixed, since you guys have been thinking about this one for awhile aready :)

@starbow: lovely suggestions, thanks.

Sadly, there's not a hook to easily turn the "Create" link into a "Create New Issue" link on the issue query result pages, so that part might be more tricky. I'd have to look a little closer -- maybe we can tweak it in the theme or something. Quick skim seems like it'd be pretty easy to just add another alter hook for this. ;)

But a "(start here to report new issue)" qualifier on the end of the text is a no-brainer and easily accomplished. At the risk of soliciting a bikeshed discussion, I'd like a little feedback on that wording, though:

a) "start here to report new issue"

b) "start here to create a new issue"

c) "you can create new issues here"

... ?

I vote for a)

Could we change 'Create' to 'Create new issue' in project* itself, seems like sites could use string-overrides to change it back to 'Create' if they really care.

I'd say b. If it says "Create" on the next page we should be consistant from page to page.
Although, a & "Report New Issue" on the next page would be ideal :)

I didn't even see the new "create" link buried in the headers of the issue table.

You just made it much more difficult for people to report issues, which will in turn lead to less reporting of bugs or requesting of features, lowering the quality of some modules.

@dugh: The "create" link at the top of issue query pages isn't new, it's been around forever. All the more evidence to support the assertion that it's easily missed. ;)

While I agree with the thrust of this issue and support any effort to reduce duplicates, I also agree that the currently-deployed code is not ideal. I just need to either convince the other project* maintainers that we should change the "create" link to something else directly in project_issue.module, or add a way to more easily customize those links per-site -- if not a full-blown alter hook like the links on project pages, at least wrapping them in a theme function. See #329508-1: Make link to report bugs more clear and prominent for more on that.

After that lands, all we need is something like this in drupal.org's template.php file:

function phptemplate_project_issue_query_result_links($links) {
  if (!empty($links['create']['href'])) {
    $links['create']['title'] = t('Create a new issue');
  }
  return theme('links', $links);
}

(Note: the 'create' link is rendered as "Login or register to create an issue" for anonymous users, and in that case 'href' is empty, the title includes the HTML for the "Login" and "register" parts, and $links['create']['html'] is TRUE).

Also, here's a patch for drupalorg.module to change the text of the link on the project page itself.

I actually agree with dugh, in that I do think this change makes it much harder for people to figure out how to report issues. This could result in a decrease in duplicate issues (as sun suggests has happened), but it seems to me that it would also decrease the number of bugs reported and features requested. Whether or not the overall quality of a particular module changes is hard to measure and predict, however.

I really feel that removing the "Create a new bug report\feature request\etc." from the project overview page is more of a band aid solution to this problem. I think that ultimately changes to the project issue module that attempt to automatically find potential duplicates or changes in submission work flow will be more effective, at least in the long term. But those changes also take more time and effort and therefore are not likely to come about quickly.

I do think that dww's patch in #41 will help with this a bit, but I'm not convinced that changing "Create" to "Create a new issue" is going to make it that much easier for new users to figure out how to create a new issue. But I certainly think it's an improvement over what we're doing right now.

I also agree this issue is a band-aid. We certainly want #19386: Automatically search for duplicate issues/questions before submitting new issue/question, but that is indeed a larger task. Meanwhile, as I said, "I support any effort to reduce duplicates". ;)

FYI: deployed all of this and #329508-1: Make link to report bugs more clear and prominent on p.d.o for people to play with it live:
http://project.drupal.org/project/drupal
http://project.drupal.org/project/issues/drupal

Based on feedback in IRC, we decided "View open issues or report a new issue" would be nicer.

We went with "View open issues or create a new one". Committed to drupalorg.module and deployed on d.o (and p.d.o).

This was a discussion about implementing these changes on the drupal.org version of project.

#426610: Consolidate, Rearrange and Remove issue creation links from project pages is asking about the same thing in the general Project project.

Pointing people there who might find this via google like I did.

"We went with "View open issues or create a new one"."

It's been broken again. There is no longer a link from the project page to report a bug or request a feature, only a link to look at patches. If you 'look at patches' then there is a link to create an issue, but still I cannot see how to view existing bugs and feature requests.

@dugh: Well, we have the blocks which have

All issues
45 open, 800 total
Bug reports
2 open, 216 total

and all of those are links. Could add FRs, I suppose. That's up to dww. If you think that shoudl be there, file a new issue.

Michelle