The current block labels make it hard to find both of the blocks. By standardizing on "Module name: blah" it should be easier to find them.

CommentFileSizeAuthor
#3 1853486_project_issue_block_names_simpler_2.patch665 bytesgreggles
#1 1853486_project_issue_block_names_simpler.patch646 bytesgreggles

Comments

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Needs review
StatusFileSize
new 1853486_project_issue_block_names_simpler.patch646 bytes
dww’s picture

dww
we/he/they
commented
Status: Needs review » Needs work

Yeah, I've thought about this myself on a couple of occasions. The reason it's still inconsistent is the "issue cockpit" block is something about projects -- a summary of the entire issue queue for a given project, meant to be displayed on project nodes. The other is a block representing all the metadata fields about a given issue, meant to be displayed on issue nodes themselves. So I thought it made sense to have all the blocks that are meant to be associated with projects start with "Project:" (regardless of which module provides the block) and all the ones meant to be associated with issues start with "Project issue".

I think if we're going to change these names to always start with "Project issue:" we should consider changing the rest of each name to make this difference more clear.

I'm open to good suggestions. ;) Here's a start:

Project issue: Issue queue statistics
Project issue: Per-issue metadata

? Or something.

Thoughts?

Thanks!
-Derek

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Needs work » Needs review
StatusFileSize
new 1853486_project_issue_block_names_simpler_2.patch665 bytes

Indeed, those two make a ton of sense to me.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Reviewed & tested by the community

greggles: do you want to be a co-maintainer of Project* so you can commit RTBC bug fixes like this and help work on stuff like #1852386: Create point 7.x releases of Project* - support database updates between [un]stable releases? ;)

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

I'm open to the idea :)

I promise to always post patches to issues first, wait some time before committing, use the proper commit message style, and link from a comment where I close an issue to the commit where it happened.

My focus is very much 7.x so my only remaining question is whether to move things to "patch (to be ported)" or just "Fixed." Maybe that's just a case-by-case decision.

dww’s picture

dww
we/he/they
commented
Assigned: Unassigned » greggles

Sorry it took a few days to get back to this. I just split off the co-maintainer thing to #1859474: Add greggles as a co-maintainer for Project* for clarity.

Meanwhile, please commit this at will. In this case, I think a backport here is more trouble than it's worth.

Thanks!
-Derek

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Reviewed & tested by the community » Fixed

Committed to 7.x then - http://drupalcode.org/project/project_issue.git/commit/10bf487

I don't think this makes sense to backport. The only block in 6.x for project_issue is "Project Issue Summary" which seems pretty clear.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.