actually, now that i did it on a test site, i'm not sure i like this. ;) rather, i'd like there to be a way to turn it on/off (either as a separate URL, arguments in $_REQUEST, and/or a form element of some kind). i've got CVS access on a few projects that would overwhelm my usual view of my projects (like OG). it'd be nice to still provide all projects you really own vs. all projects you just co maintain/help with...
but, here's a patch for the always-show-everything approach, as a starting point. ;)
The patch itself (visually) appears to be fine. However, I believe that (while it is off-topic and might not matter in this case) $tablesort_sql should just be appended rather than substituted via a %s in the query in question.
the trouble w/ tabs is what URL to use. "/project/user/dww" works for anyone to see all projects owned by dww. ditto with a uid (e.g. /project/user/1 shows you all of Dries's projects). so, if we try to make tabs at /project/user/ we need something like "/project/user/owner" and "project/user/maintainer" which would then a) potentitally conflict with any usernames like that or b) we'd break everyone's existing bookmarks...
IMO the proper way to handle this is with subscription options. The same way you can "subscribe" to individual issues (by posting a reply), which show up under "My issues", you should be able to "subscribe" to individual projects, which show up under "My projects." This way you can follow projects' issues whether you are a co-maintainer or not, and maintainers could ignore projects they no longer care about or whatever. ;)
Any project you are a maintainer or co-maintainer of would have a subscription flag for it automatically, but you could also unsubscribe through a theoretical robust subscriptions interface. ;) I imagine there's an issue for this already.
Angie, I'm not sure that would work for me; I'm already subscribed to several projects, most of which I am not a maintainer for and wouldn't want on my "My projects" list.
Right. That's why you would have the ability to unsubscribe from projects you don't want, same as you would issues under this hypothetical feature. See http://drupal.org/node/34496.
Btw, you don't even need something as fancy as Subscriptions module for this. Views Bookmark is a module which would be more aptly named "Arbitrary Node Flags." You simply add a "Subscribe" bookmark to projects and issues, and have your "My projects" View display nodes that have that flag on, with an RSS argument to show the feed icon at the bottom. Same for "My issues". Simple. I click the link to add it to my list, I click the link to remove it from my list. And no more responding "subscribe" to issues anymore. ;)
Would of course need review by security team, etc. etc.
I want to remain subscribed to the other modules so I get email about those issues that I might be able to help with, such as I promised Derek. But they are not projects for which I am responsible - those are the ones I want in the "My Projects" list. So maybe the bookmarks solution is better - I could flag some as "My Projects" and others as "Following."
According to http://drupal.org/node/27367 (and if it is current), neither Subscriptions nor Views Bookmark are used on d.o. If I remember correctly, it will be quite a task getting either on them in use here. Am I correct on that? Regardless of how difficult it may or may not be, is there a documented process of the steps necessary to get a module on d.o?
Also, according to the project nodes, Views Bookmark is being replaced by Flag (http://drupal.org/project/flag), which might be more of what webchick was talking about.
I would also like to see this functionality, and I am willing to help out in whatever capacity I can.
after #69556: move "cvs access" tab into project, make it generic this issue gets more complicated, like: 'My projects' should also display projects where I have some maintainer rights.
Could be the status changed to active, or is it still postponed on something?
In terms of the tab/URL woes I mentioned in #4, probably we should always use /project/user/[username]. So, /project/user can just redirect to /project/user/[username] which gives you the default owner tab (which is technically /project/user/[username]/owner). But, you can also click on the "Maintainer" tab to get to /project/user/[username]/maintainer. In the future, we'd add /project/user/[username]/subscribed (or something).
This is all based on views now, so it should be pretty easy to do. We'll need a trivial menu callback that lives at /project/user itself to do the redirects, but otherwise, this should almost entirely be possible via clicking it together. The however, it's possible I didn't export enough data to views over at #69556: move "cvs access" tab into project, make it generic so we might need some additional views support in project_issue.
Having the projects you own and those that you co-mantain somehow in "your projects" tab would be very useful indeed, specially now that the co-mantaining permissions is more granular now.
Re: "Anything we can do to move this issue along?"
Certainly. I spelled out the plan in #22 -- you can just do it. You can start with the http://drupal.org/project/drupalorg_testing install profile and upgrade to the latest project and project_issue code from CVS HEAD. Then you can try clicking the new views together. If you get it working, you can export the views to code, and paste them here, or better yet, create a patch that modifies the existing default view (if necessary) and adds the new views as separate files in project_issue/views/default_views. If we in fact need the menu callback I mentioned in #22, that'd be a patch for project_issue.module.
Hi dww,
I've tried to start working on this issue, but when I download the Drupalorg testing profile and install it, it seems that there is not Maintainers Tab in the project page as there is in drupal.org, so I can't give access to more than one user to a project, how can I have the maintainers tab enabled?
The consequences of co-maintained projects not showing up in your "My projects" view are now worse with sandbox projects. There is no way to guess your way back to the URL, and sandboxes aren't showing up in search results. (At least currently; dww and pwolanin are looking into it.)
Leisa and I were discussing this the other day in the context of some Prairie Initiative stuff looking at the contributor UX on d.o. I think a staging site is a bit premature. At this point, we mainly need a design/plan. Some ideas:
- The current page is really two totally separate things: a table of your projects with some quick-links for maintainers vs. a custom query of issues from all your projects. Neither is particularly effective since one page is trying to do both.
- We should move the issue view entirely to a subtab of "Your Issues", and then redesign this "Your Projects" page to just focus on the first thing -- the table of your projects. *That* could easily be tabbed (or perhaps even multiple tables down the page) for "Projects you own" vs. "Projects you (co)maintain" vs. "Projects you follow" (or something). If the page is just trying to do this one thing, it'd be possible to include more useful links or metrics (or both) in the project table, without fear of pushing the issue view so far below the fold no one knows it's there or can use it.
- "Your issues" would then have tabs for separate views for something like:
Issues from topics you follow (eventually -- see Creating Topic Pages for more on "topics")
The exact labels are still TBD, but this is the basic idea. Point being the issue view at the bottom of the current "Your Projects" page is really about issues, not projects. Hence, it should live with "Your Issues" not "Your Projects".
Anyway, before we bolt more stuff onto this page, I'd like to see a more holistic plan for how to clean up the user dashboard/profile section to make more sense...
Totally a good effort, any effort that happens with pages that are currently not so usable is good.
I'm currently not aware on how I can help this effort get some traction but I'd love to help
I'm helping out with support for a few projects and have got some _special_ role by the maintainers so that I can assign issues to any of the (co)maintainers and also update the project page.
Being able to get an overview of my roles for projects would be really useful to have on my account page.
Would of course also be nice if that information also was shown on the public profile page as well.
I would also like to suggest that the "Maintainers for [project]" block on the project pages could be renamed to "[project] team members" and then list the various roles and users for it.
@tsvenson: Your proposal about the "Maintainers for [project]" block needs to go into a new issue. That's off-topic for this thread. This is just about issue listings as I described at #36.
Comments
#1
yup. i've thought the same thing for quite a while. i'm all in favor of this.
#2
actually, now that i did it on a test site, i'm not sure i like this. ;) rather, i'd like there to be a way to turn it on/off (either as a separate URL, arguments in $_REQUEST, and/or a form element of some kind). i've got CVS access on a few projects that would overwhelm my usual view of my projects (like OG). it'd be nice to still provide all projects you really own vs. all projects you just co maintain/help with...
but, here's a patch for the always-show-everything approach, as a starting point. ;)
#3
Tabs perhaps?
The patch itself (visually) appears to be fine. However, I believe that (while it is off-topic and might not matter in this case) $tablesort_sql should just be appended rather than substituted via a %s in the query in question.
-K
#4
the trouble w/ tabs is what URL to use. "/project/user/dww" works for anyone to see all projects owned by dww. ditto with a uid (e.g. /project/user/1 shows you all of Dries's projects). so, if we try to make tabs at /project/user/ we need something like "/project/user/owner" and "project/user/maintainer" which would then a) potentitally conflict with any usernames like that or b) we'd break everyone's existing bookmarks...
#5
I see. Perhaps following the tracker module might be helpful..
Offhand,
/project/user/uid (or username)shows the projects page for user uid./user/uid/projectshows my project page. This is linked to by "My projects".This has the added benefit of being displayed in the user's account pages.
Cheers,
-K
#6
Interesting, and when will we get this in? 7 months without a change is a long time...
#7
@hass: it will get in when somebody codes it properly. are you volunteering?
what about a main table with what's there now, and a 'Projects with commit access' table in a collapsible fieldset?
#8
So, I guess the answer to http://drupal.org/node/199093 is no.
#9
IMO the proper way to handle this is with subscription options. The same way you can "subscribe" to individual issues (by posting a reply), which show up under "My issues", you should be able to "subscribe" to individual projects, which show up under "My projects." This way you can follow projects' issues whether you are a co-maintainer or not, and maintainers could ignore projects they no longer care about or whatever. ;)
Any project you are a maintainer or co-maintainer of would have a subscription flag for it automatically, but you could also unsubscribe through a theoretical robust subscriptions interface. ;) I imagine there's an issue for this already.
#10
Angie, I'm not sure that would work for me; I'm already subscribed to several projects, most of which I am not a maintainer for and wouldn't want on my "My projects" list.
#11
Right. This should all be handled via subscriptions and views. This is a fine issue to discuss this particular feature in.
#12
Right. That's why you would have the ability to unsubscribe from projects you don't want, same as you would issues under this hypothetical feature. See http://drupal.org/node/34496.
#13
Sorry! Didn't mean to change status.
#14
Btw, you don't even need something as fancy as Subscriptions module for this. Views Bookmark is a module which would be more aptly named "Arbitrary Node Flags." You simply add a "Subscribe" bookmark to projects and issues, and have your "My projects" View display nodes that have that flag on, with an RSS argument to show the feed icon at the bottom. Same for "My issues". Simple. I click the link to add it to my list, I click the link to remove it from my list. And no more responding "subscribe" to issues anymore. ;)
Would of course need review by security team, etc. etc.
#15
I want to remain subscribed to the other modules so I get email about those issues that I might be able to help with, such as I promised Derek. But they are not projects for which I am responsible - those are the ones I want in the "My Projects" list. So maybe the bookmarks solution is better - I could flag some as "My Projects" and others as "Following."
#16
According to http://drupal.org/node/27367 (and if it is current), neither Subscriptions nor Views Bookmark are used on d.o. If I remember correctly, it will be quite a task getting either on them in use here. Am I correct on that? Regardless of how difficult it may or may not be, is there a documented process of the steps necessary to get a module on d.o?
Also, according to the project nodes, Views Bookmark is being replaced by Flag (http://drupal.org/project/flag), which might be more of what webchick was talking about.
I would also like to see this functionality, and I am willing to help out in whatever capacity I can.
#17
#289124: show co-maintained modules in "My projects" has been marked as a duplicate of this issue. I'm also unassigning dww since I think he would have finished this by now if he were really working on it :)
#18
+1
Skim-reading the comments it looks like we're making this a lot more complicated than it needs be...
#19
+1 for this. It really seems like integration with the Flag module would be best.
#20
Any further developments on this idea now that d.o. is running the 6.x version of project issue tracking?
#21
after #69556: move "cvs access" tab into project, make it generic this issue gets more complicated, like: 'My projects' should also display projects where I have some maintainer rights.
Could be the status changed to active, or is it still postponed on something?
#22
Sure, we can make it active. I think how it needs to work is separate tabs under "My projects" for:
- Projects you own (current behavior, default tab)
- Project you're any kind of maintainer on (using the new project maintainer data)
In the future, we can add:
- Projects you subscribed to (based on flag, still blocked/postponed on #34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment)
In terms of the tab/URL woes I mentioned in #4, probably we should always use /project/user/[username]. So, /project/user can just redirect to /project/user/[username] which gives you the default owner tab (which is technically /project/user/[username]/owner). But, you can also click on the "Maintainer" tab to get to /project/user/[username]/maintainer. In the future, we'd add /project/user/[username]/subscribed (or something).
This is all based on views now, so it should be pretty easy to do. We'll need a trivial menu callback that lives at /project/user itself to do the redirects, but otherwise, this should almost entirely be possible via clicking it together. The however, it's possible I didn't export enough data to views over at #69556: move "cvs access" tab into project, make it generic so we might need some additional views support in project_issue.
#23
Tracking.
#24
Having the projects you own and those that you co-mantain somehow in "your projects" tab would be very useful indeed, specially now that the co-mantaining permissions is more granular now.
#25
Anything we can do to move this issue along?
#26
Re: "Anything we can do to move this issue along?"
Certainly. I spelled out the plan in #22 -- you can just do it. You can start with the http://drupal.org/project/drupalorg_testing install profile and upgrade to the latest project and project_issue code from CVS HEAD. Then you can try clicking the new views together. If you get it working, you can export the views to code, and paste them here, or better yet, create a patch that modifies the existing default view (if necessary) and adds the new views as separate files in project_issue/views/default_views. If we in fact need the menu callback I mentioned in #22, that'd be a patch for project_issue.module.
Good luck,
-Derek
#27
Hi dww,
I've tried to start working on this issue, but when I download the Drupalorg testing profile and install it, it seems that there is not Maintainers Tab in the project page as there is in drupal.org, so I can't give access to more than one user to a project, how can I have the maintainers tab enabled?
Thanks
#28
#29
Yeah, right, sorry about that, I have it working now.
I'm working on it
#30
Looking forward to see this.
#31
The consequences of co-maintained projects not showing up in your "My projects" view are now worse with sandbox projects. There is no way to guess your way back to the URL, and sandboxes aren't showing up in search results. (At least currently; dww and pwolanin are looking into it.)
#32
Marked #1200726: View co-maintaining projects under Your Projects? as a duplicate of this
#33
Sub
#34
Subscribing to keep track of this. I'm going to take a stab at it when I have some time to dedicate.
#35
I started the buildout of a dev site called myprojects for this. Details on our setup are at http://drupal.org/node/1018084.
#36
Leisa and I were discussing this the other day in the context of some Prairie Initiative stuff looking at the contributor UX on d.o. I think a staging site is a bit premature. At this point, we mainly need a design/plan. Some ideas:
- The current page is really two totally separate things: a table of your projects with some quick-links for maintainers vs. a custom query of issues from all your projects. Neither is particularly effective since one page is trying to do both.
- We should move the issue view entirely to a subtab of "Your Issues", and then redesign this "Your Projects" page to just focus on the first thing -- the table of your projects. *That* could easily be tabbed (or perhaps even multiple tables down the page) for "Projects you own" vs. "Projects you (co)maintain" vs. "Projects you follow" (or something). If the page is just trying to do this one thing, it'd be possible to include more useful links or metrics (or both) in the project table, without fear of pushing the issue view so far below the fold no one knows it's there or can use it.
- "Your issues" would then have tabs for separate views for something like:
The exact labels are still TBD, but this is the basic idea. Point being the issue view at the bottom of the current "Your Projects" page is really about issues, not projects. Hence, it should live with "Your Issues" not "Your Projects".
Anyway, before we bolt more stuff onto this page, I'd like to see a more holistic plan for how to clean up the user dashboard/profile section to make more sense...
#37
Sounds great!
#38
dww's suggestion in #36 sounds amazing. Would that be difficult?
I wouldn't want this issue to get held up if it would be simpler in the interim just to make a single separate tab for the co-maintained projects.
#39
Totally a good effort, any effort that happens with pages that are currently not so usable is good.
I'm currently not aware on how I can help this effort get some traction but I'd love to help
#40
I'm helping out with support for a few projects and have got some _special_ role by the maintainers so that I can assign issues to any of the (co)maintainers and also update the project page.
Being able to get an overview of my roles for projects would be really useful to have on my account page.
Would of course also be nice if that information also was shown on the public profile page as well.
I would also like to suggest that the "Maintainers for [project]" block on the project pages could be renamed to "[project] team members" and then list the various roles and users for it.
#41
@tsvenson: Your proposal about the "Maintainers for [project]" block needs to go into a new issue. That's off-topic for this thread. This is just about issue listings as I described at #36.
Thanks,
-Derek
#42
I'd love to see this happen on d.o! especially as described in #36