Maintainer Views Meta Issue

[ewdurbin]

Goals of this Issue

Classify, describe, and share the current functionality implemented by PyPI to assist contributors while developing warehouse's maintainer UI.

THIS IS NOT THE CORRECT ISSUE FOR FILING BUGS OR FEATURE REQUESTS REGARDING A MAINTAINER ACTIVITY

Proposed hierarchy

maintainer-views
├── account
│   ├── email_address
│   ├── openids
│   ├── password
│   └── pgp_key_id
└── projects
└── PROJECT_NAME
├── releases
│   ├── RELEASE_VERSION
│   │   ├── PKG-INFO
│   │   ├── files
│   │   └── journal
│   └── list
├── PKG-INFO
├── documentation
├── journal
├── roles
└── view

Legend

• regular text is a "file"

These are not necessarily their on page but "resources" or "fields" that could be updated.

• bold indicates "directory"

These will either contain links to the resources or data presented in a resource.

Current views as implemented in pypi-legacy

maintainer-views/ (root)

https://pypi.python.org/pypi

Note: The box in the top right effectively serves as our maintainer-views/projects view at all times.

maintainer-views/account view

https://pypi.python.org/pypi?%3Aaction=user_form

Includes "resources":

• email_address
• openids
• password
• pgp_key_id

maintainer-views/projects/PROJECT_NAME view

https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=PROJECT_NAME

Includes "resources":

• releases
• documentation

With links to

• roles
• view

maintainer-views/projects/PROJECT_NAME/roles

https://pypi.python.org/pypi?:action=role_form&package_name=PROJECT_NAME

maintainer-views/projects/PROJECT_NAME/view

https://pypi.python.org/pypi?name=PROJECT_NAME&:action=display

Includes "resources"

• journal

NOTE: Further on to bottom of page we include the journals for the release

maintainer-views/projects/PROJECT_NAME/releases

https://pypi.python.org/pypi?:action=pkg_edit&name=PROJECT_NAME

Includes "resources":

• release(s)
• documentation

With links to

• roles
• view

maintainer-views/projects/PROJECT_NAME/releases/RELEASE_VERSION

https://pypi.python.org/pypi?:action=files&name=PROJECT_NAME&version=RELEASE_VERSION

Includes "resources":

• file(s)

With links to:

• PKG-INFO

[nlhkabu]

thanks @ewdurbin - just a clarification on the release visibility - e.g.

I don't understand this - I thought PyPI (and warehouse) showed all of the release history for each project?

Is this setting specifying which version of the project should be shown as the default? e.g. in warehouse - the version which would be linked to from the search results, and have this badge:

?
Thanks

[ewdurbin]

That's effectively what's afoot @nlhkabu.

What is trying to be accomplished here is allowing a maintainer to push a pre-release to PyPI without having it show as the default release for their project.

PyPI will always allow you to view "Hidden" releases which aren't deleted by heading to a direct URL.

If more than one release is set to "Hide?" => "No" the project release page ends up looking like:

https://pypi.python.org/pypi/PROJECT_NAME

instead of

I don't have a strong opinion one way or the other on whats right or where to go from here...

[dstufft]

Release visibility as a concept doesn't exist in Warehouse. It's a legacy PyPI thing.

[nlhkabu]

@dstufft does this mean that we can ignore "giving package maintainers a way to manage hidden vs unhidden releases" in #424 (comment)?

Or, should I continue to design the UI with the view of introducing this functionality to Warehouse?

[dstufft]

Yea we can ignore it. It is confusing and bad. Warehouse just always shows the latest.

…

Sent from my iPhone

On Jan 6, 2018, at 5:32 PM, Nicole Harris ***@***.***> wrote: @dstufft does this mean that we can ignore "giving package maintainers a way to manage hidden vs unhidden releases" in #424 (comment)? Or, should I continue to design the UI with the view of introducing this functionality to Warehouse? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[nlhkabu]

Initial design specification for project page:

Notes:

• The release page remains the main page of a project, with 'roles and permissions', 'documentation' and 'journal' pages as supplement.
• 'Roles and permissions' - could/should rename to 'collaborators' as per the current terminology?
• Does documentation need it's own page? to discuss?

From a design/front end perspective, this proposal requires a few new components:

1. modal
2. button with dropdown menu. Might be able to reuse some of the code from the header dropdown
3. sub links in side menu

[ewdurbin]

Only thoughts so far is that we probably want to collect all destructive actions into a specific place... deleting a project, release, or file isn’t particularly encouraged and we should keep the UI elements for that out of the main path.

[di]

My initial thoughts:

1. I had some comments about the "roles" form, but I think we've addressed it in Role Management #2705.
2. I'm not sure I see the value in listing all the user's projects on the left-hand-side menu. I'm concerned about what this would look like if the user maintained more than just a few projects. I think it makes more sense to have a "list all my projects" page and make it easy for the user to return to it from here instead.
3. Assuming the previous makes sense, I think everything on the right hand dropdown could probably get included in what remains of the left hand menu, or as part of something already on the left hand menu. Similar to a repository's "Settings" tab on Github:

Worth noting that the "destructive action" of deleting a repository is included at the bottom of the "Options" page here.

'Roles and permissions' - could/should rename to 'collaborators' as per the current terminology?

👍 I think we should take this as an opportunity to revise the terminology for these pages. In #2705 I called this "Collaboration" which I think is more clear, "Journals" could become "Project History", etc.

[nlhkabu]

Hi @ewdurbin and @di - thanks for your feedback!

Latest UI:

Regarding destructive actions - I think a better way to deal with this is to ask the user to confirm their action (see #2808 and #2805) rather than hiding it in the UI. This means we can keep it in a location with other actions, but also treat it like dynamite ;P Does this address your concerns?

Regarding listing the projects on the left - what would the most projects we could expect a user to have? The reason I have opted to include it here is to provide a shortcut for users - as this currently exists in the old PyPI interface. I have also included a link back to the main project page, to cover both bases.

I've opted to put the menu items as tabs because there are not that many :) I don't think combining the tabs and the 'project options' links into one place will work because some open a new page, where others complete an action.

Anyway, please pull down the latest via the 'role-management' branch to take a look 😁

[dstufft]

Regarding listing the projects on the left - what would the most projects we could expect a user to have? The reason I have opted to include it here is to provide a shortcut for users - as this currently exists in the old PyPI interface. I have also included a link back to the main project page, to cover both bases.

A lot.

warehouse-prod::DATABASE=> SELECT user_name, COUNT(*) as num from (SELECT DISTINCT user_name, package_name FROM roles) a GROUP BY user_name ORDER BY num DESC LIMIT 10;
  user_name  | num
-------------+------
 OCA         | 3146
 openstackci |  612
 davisagli   |  514
 hannosch    |  508
 faassen     |  403
 icemac      |  401
 agroszer    |  355
 tlotze      |  330
 srichter    |  328
 projekt01   |  314
(10 rows)

[di]

Thanks for the update @nlhkabu! Responses below:

Regarding destructive actions - I think a better way to deal with this is to ask the user to confirm their action (see #2808 and #2805) rather than hiding it in the UI. This means we can keep it in a location with other actions, but also treat it like dynamite ;P Does this address your concerns?

I think this makes sense.

Regarding listing the projects on the left - what would the most projects we could expect a user to have? The reason I have opted to include it here is to provide a shortcut for users - as this currently exists in the old PyPI interface. I have also included a link back to the main project page, to cover both bases.

Besides the potential length for this list, I don't think that users will be switching back and forth between projects so much that this shortcut is necessary. The usual flow is probably something like:

Log in -> find a project -> perform some action -> leave

I've opted to put the menu items as tabs because there are not that many :) I don't think combining the tabs and the 'project options' links into one place will work because some open a new page, where others complete an action.

There likely will be more of these in the future, so it might be preferable to be able to expand vertically rather than horizontally.

I was suggesting that anything in this menu that performs an action would just exist under an "Options" tab/page instead, similar to the "Options" page for a github repo. I think it would be better to have these in the same place as the other project management subpages rather than a separate button/dropdown.

It also makes all these pages a little simpler, as the "Project Options" dropdown and corresponding forms/modals won't need to exist on every management page.

[nlhkabu]

Ok, thanks everyone for your feedback and info.

Regarding the options page - I'm just worried that there will not be enough content to justify a page by itself. What other content do we imagine could go on this page in the future?

TODOs on my side:

• Move tabs to left hand menu, in place of project links. Retain link back to main projects list.

List of Projects

Given some users have many projects (as highlighted by Donald above) should we add pagination to the list of projects currently located at:

• warehouse/templates/manage/projects.html
• warehouse/templates/accounts/profile.html

Should we open a new ticket for these?

@di do you want this done before merging #2705 or are you happy to merge and have fixes down the line?

[di]

What other content do we imagine could go on this page in the future?

• Deleting the project (Enable deleting a project #2805)
• Deleting pythonhosted documentation (Add the ability to delete "legacy" documentation #582)
• Renaming the project (functionality to rename a project #1919)
• Requesting a upload limit increase (Dedicated mechanism for requesting a large file limit #2017)
• Enabling staged releases (Draft release feature on main archive to allow testing a release before it goes live #726)
• Enabling project-specific API keys (Add support for API keys #994)

Given some users have many projects (as highlighted by Donald above) should we add pagination to the list of projects currently located at:

I think it'd be preferable to include a simple client-side search instead, especially if projects are ordered by most recently updated and not alphabetically (although this would definitely be post-MVP) -- so let's make an issue for it.

@di do you want this done before merging #2705 or are you happy to merge and have fixes down the line?

Either's fine with me!

[di]

This has been addressed!