New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define criteria for listing clients on NuGet.org’s package details page #4510

Closed
unniravindranathan opened this Issue Aug 4, 2017 · 20 comments

Comments

Projects
None yet
@unniravindranathan

unniravindranathan commented Aug 4, 2017

For reference, see this pull request from Paket as an additional tab: #4437

@falfaddaghi

This comment has been minimized.

Show comment
Hide comment
@falfaddaghi

falfaddaghi Aug 4, 2017

why should there be any criteria aside from being an actual working client? as stated in the last pr maven lists multiple clients. I don't understand the reluctance here at all. can you maybe explain your concerns? if nuget change a protocol and that break Paket which in turn makes the command displayed not correct how does that affect nuget.org ?

falfaddaghi commented Aug 4, 2017

why should there be any criteria aside from being an actual working client? as stated in the last pr maven lists multiple clients. I don't understand the reluctance here at all. can you maybe explain your concerns? if nuget change a protocol and that break Paket which in turn makes the command displayed not correct how does that affect nuget.org ?

@unniravindranathan

This comment has been minimized.

Show comment
Hide comment
@unniravindranathan

unniravindranathan Aug 4, 2017

@falfaddaghi I will admit that I don't have a well-thought out response yet, so please consider this as me just thinking out loud - curious what you think?

  • Once we agree that a particular experience is core to the .NET developer experience (security, platform support, etc.) - should we mandate that the client support that? How do we reason with the urgency around supporting a particular experience - wait for everyone to be ready, etc.?

  • Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more (hard to know for sure, since we don't have a contract for the client to share a well know name and version :( ). What is the objective criteria we can use here to triage requests?

  • We will almost certainly need to do additional more UX work to give the user more information so they can make an informed choice about who supports the client, what scenarios work, what don't, and so on.

unniravindranathan commented Aug 4, 2017

@falfaddaghi I will admit that I don't have a well-thought out response yet, so please consider this as me just thinking out loud - curious what you think?

  • Once we agree that a particular experience is core to the .NET developer experience (security, platform support, etc.) - should we mandate that the client support that? How do we reason with the urgency around supporting a particular experience - wait for everyone to be ready, etc.?

  • Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more (hard to know for sure, since we don't have a contract for the client to share a well know name and version :( ). What is the objective criteria we can use here to triage requests?

  • We will almost certainly need to do additional more UX work to give the user more information so they can make an informed choice about who supports the client, what scenarios work, what don't, and so on.

@Rickasaurus

This comment has been minimized.

Show comment
Hide comment
@Rickasaurus

Rickasaurus Aug 4, 2017

Trying to maintain so much control over the .NET developer experience is what has driven so many .NET developers away in the first place. The problem is that there is no one size fits all experience. We need to be able to make and use tools that fit our particular needs. For some that is out of the box one stop shopping, for others it's customizing to reduce the burden of certain kinds of common developer tasks (this is what Paket does really well).

We are a small team with many clients and so hundreds of .NET projects. Keeping them up to date and in sync with Nuget was a maintenance nightmare. However, the standard Nuget client might be just fine for a team focused on one single or a few products.

Security is important and I think all clients should be made to be secure by enforcing a secure protocol. However, I think mandating platform support goes too far. If it works for the people who opt in to use it what's the problem? There's nothing stopping you from using the standard Nuget client in some projects and Paket in others where the dependency burden has become overwhelming.

Making the "Experience" mandate onerous will only stop people from contributing new and innovative solutions to problems, and that can only be a bad thing for the community.

Rickasaurus commented Aug 4, 2017

Trying to maintain so much control over the .NET developer experience is what has driven so many .NET developers away in the first place. The problem is that there is no one size fits all experience. We need to be able to make and use tools that fit our particular needs. For some that is out of the box one stop shopping, for others it's customizing to reduce the burden of certain kinds of common developer tasks (this is what Paket does really well).

We are a small team with many clients and so hundreds of .NET projects. Keeping them up to date and in sync with Nuget was a maintenance nightmare. However, the standard Nuget client might be just fine for a team focused on one single or a few products.

Security is important and I think all clients should be made to be secure by enforcing a secure protocol. However, I think mandating platform support goes too far. If it works for the people who opt in to use it what's the problem? There's nothing stopping you from using the standard Nuget client in some projects and Paket in others where the dependency burden has become overwhelming.

Making the "Experience" mandate onerous will only stop people from contributing new and innovative solutions to problems, and that can only be a bad thing for the community.

@ReedCopsey

This comment has been minimized.

Show comment
Hide comment
@ReedCopsey

ReedCopsey Aug 4, 2017

@unniravindranathan I'll try to reply my thoughts in line:

Once we agree that a particular experience is core to the .NET developer experience (security, platform support, etc.) - should we mandate that the client support that? How do we reason with the urgency around supporting a particular experience - wait for everyone to be ready, etc.?

Security, IMO, isn't an "experience" as much as a "platform requirement". Any client with decent support will adjust to your security concerns. I think that should be eliminated from criteria - if you have an API, and a client uses it, security should be handled (barring stupidity in the client - and major security issues, I agree, should be enough to not be listed).

That being said -

I think dictating that any specific experience is "core to the .NET developer" only restricts the .NET developers you will attract.

Make the experience better, and people will use it. That's why Paket, as an example, exists in the first place. The "official" client has significant issues with the workflow of many .NET developers. Paket provides a better experience for them. If your other issues (platform support, etc) aren't handled, people won't find it a better experience, and won't use it.

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more (hard to know for sure, since we don't have a contract for the client to share a well know name and version :( ).

I would recommend that be included in your API in the future, since you're talking about changing it anyways. However, it's tough to force even if it's there.

What is the objective criteria we can use here to triage requests?

There are many things you could use. I'll give some ideas, with Paket as an example of how proof could be supplied:

  • Usage counts: Can you document that a not-insignificant number of projects rely on this? For example, going back to Paket, it's easy to show thousands of open source projects use it today [which doesn't include commercial/private users, etc].
  • History of support: Can you show that the project is actively maintained, improved, etc? Easy if it's open source - just look at contributions/contirbutor counts/release history/etc
  • Traffic: Tough now, but if you included in API, this could easily work into criteria

We will almost certainly need to do additional more UX work to give the user more information so they can make an informed choice about who supports the client, what scenarios work, what don't, and so on.

As far as I can tell, nuget.org doesn't include anything related to the dotnet cli client. Really, documentation is just pushed off to Microsoft docs sites. I don't see why other clients should be different in this regard.

If you add UX work around this, including that any candidate to be included also add themselves in that documentation seems reasonable.

ReedCopsey commented Aug 4, 2017

@unniravindranathan I'll try to reply my thoughts in line:

Once we agree that a particular experience is core to the .NET developer experience (security, platform support, etc.) - should we mandate that the client support that? How do we reason with the urgency around supporting a particular experience - wait for everyone to be ready, etc.?

Security, IMO, isn't an "experience" as much as a "platform requirement". Any client with decent support will adjust to your security concerns. I think that should be eliminated from criteria - if you have an API, and a client uses it, security should be handled (barring stupidity in the client - and major security issues, I agree, should be enough to not be listed).

That being said -

I think dictating that any specific experience is "core to the .NET developer" only restricts the .NET developers you will attract.

Make the experience better, and people will use it. That's why Paket, as an example, exists in the first place. The "official" client has significant issues with the workflow of many .NET developers. Paket provides a better experience for them. If your other issues (platform support, etc) aren't handled, people won't find it a better experience, and won't use it.

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more (hard to know for sure, since we don't have a contract for the client to share a well know name and version :( ).

I would recommend that be included in your API in the future, since you're talking about changing it anyways. However, it's tough to force even if it's there.

What is the objective criteria we can use here to triage requests?

There are many things you could use. I'll give some ideas, with Paket as an example of how proof could be supplied:

  • Usage counts: Can you document that a not-insignificant number of projects rely on this? For example, going back to Paket, it's easy to show thousands of open source projects use it today [which doesn't include commercial/private users, etc].
  • History of support: Can you show that the project is actively maintained, improved, etc? Easy if it's open source - just look at contributions/contirbutor counts/release history/etc
  • Traffic: Tough now, but if you included in API, this could easily work into criteria

We will almost certainly need to do additional more UX work to give the user more information so they can make an informed choice about who supports the client, what scenarios work, what don't, and so on.

As far as I can tell, nuget.org doesn't include anything related to the dotnet cli client. Really, documentation is just pushed off to Microsoft docs sites. I don't see why other clients should be different in this regard.

If you add UX work around this, including that any candidate to be included also add themselves in that documentation seems reasonable.

@falfaddaghi

This comment has been minimized.

Show comment
Hide comment
@falfaddaghi

falfaddaghi Aug 4, 2017

@unniravindranathan
I am sorry but I still do not understand the issue here. the PR was for adding a single tab for a single client Paket. I don't know how many other clients have a similar pr, but I still fail to see how that affected the Paket PR. if it get to a point that there are too many tabs simply say that a ux redesign is needed before any more tabs can be added.

As for your first point my thoughts are as follows.
I choose what is core to my experience as a .net developer and I don't like people dictating to me what it should be. that being said I understand that nuget.org can have there own standards, but I fail to see how that effects third party clients. why should the nuget team care at all what client I decide to use. Its the same for support why anyone would expect nuget to support a third party client doesn't make sense and is solved by adding a disclaimer that the nuget team isn't responsible for third party clients.

I guess what is most confusing to me right now is why even OSS the nuget.org site. what were the goals of doing that if this type of PR is going to cause such an issue? maybe if that goal was made clear things would make more sense.

all that being said I really appreciate you thinking out loud.

falfaddaghi commented Aug 4, 2017

@unniravindranathan
I am sorry but I still do not understand the issue here. the PR was for adding a single tab for a single client Paket. I don't know how many other clients have a similar pr, but I still fail to see how that affected the Paket PR. if it get to a point that there are too many tabs simply say that a ux redesign is needed before any more tabs can be added.

As for your first point my thoughts are as follows.
I choose what is core to my experience as a .net developer and I don't like people dictating to me what it should be. that being said I understand that nuget.org can have there own standards, but I fail to see how that effects third party clients. why should the nuget team care at all what client I decide to use. Its the same for support why anyone would expect nuget to support a third party client doesn't make sense and is solved by adding a disclaimer that the nuget team isn't responsible for third party clients.

I guess what is most confusing to me right now is why even OSS the nuget.org site. what were the goals of doing that if this type of PR is going to cause such an issue? maybe if that goal was made clear things would make more sense.

all that being said I really appreciate you thinking out loud.

@WilliamOckham

This comment has been minimized.

Show comment
Hide comment
@WilliamOckham

WilliamOckham Aug 5, 2017

There is no reason for this to be an issue. Consider this alternative. Give every third party client who asks for it a tab, but nobody sees them without taking a specific action. Create two URLs for every client (including the official Microsoft ones), something like nuget.org/paket/add and nuget.org/paket/remove. If I visit the add URL, then I see the tab for Paket, until I visit the remove URL Leave it to the third party clients to direct people to their add URL.

If I visit nuget.org without having visited any of the add/remove URLs (or having removed all the tabs), then show me the Microsoft clients' tabs.

WilliamOckham commented Aug 5, 2017

There is no reason for this to be an issue. Consider this alternative. Give every third party client who asks for it a tab, but nobody sees them without taking a specific action. Create two URLs for every client (including the official Microsoft ones), something like nuget.org/paket/add and nuget.org/paket/remove. If I visit the add URL, then I see the tab for Paket, until I visit the remove URL Leave it to the third party clients to direct people to their add URL.

If I visit nuget.org without having visited any of the add/remove URLs (or having removed all the tabs), then show me the Microsoft clients' tabs.

@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Aug 5, 2017

Maybe add to Reed's list:

  • Presence of unique features (which make the client uniquely useful in special use cases)

cdrnet commented Aug 5, 2017

Maybe add to Reed's list:

  • Presence of unique features (which make the client uniquely useful in special use cases)
@ReedCopsey

This comment has been minimized.

Show comment
Hide comment
@ReedCopsey

ReedCopsey Aug 5, 2017

@cdrnet I had left that out because feature worth seems very subjective... somethi ng important to a group of users may seem trivial to others. I figured usage covers that; if a client doesn't provide unique features, I don't see how they'd grow a user base, especially given that nuget is "in the box" ( in vs, dotnet tooling, etc)

ReedCopsey commented Aug 5, 2017

@cdrnet I had left that out because feature worth seems very subjective... somethi ng important to a group of users may seem trivial to others. I figured usage covers that; if a client doesn't provide unique features, I don't see how they'd grow a user base, especially given that nuget is "in the box" ( in vs, dotnet tooling, etc)

@panesofglass

This comment has been minimized.

Show comment
Hide comment
@panesofglass

panesofglass Aug 7, 2017

I find it amusing that attempts at blocking additional package managers is so easily overridden by means of a trivial browser extension like paket-attacket (which is a terrible name). For what it's worth, the new NuGet Gallery, while it looks nice, is still only useful to me as a means of looking up versions and their related dependencies when things go sideways (i.e. Google's packages). I don't know anyone who uses the NuGet Gallery to figure out how to install a package. However, I imagine the installation instructions being useful to newer employees using NuGet for the first time. They are not going to care about any one-sided decisions you may have made if their employer uses paket or another third-party client. They will just be left confused and unable to use your site or worse, get themselves in some trouble for using the wrong tool.

The most worthwhile point I've seen hasn't come from the Microsoft team but by commentors: adding additional clients could eventually become a problem due to space constraints. I would assume that would be a good problem to have. I personally have no idea why anyone would care about whose client is used. They are just tools. The best news is that everyone is happy with the NuGet package system. I remember the package manager confusion several years ago (as well as how Microsoft poorly handled that situation with the community). This is definitely not that. You actually have community members trying to work with you.

panesofglass commented Aug 7, 2017

I find it amusing that attempts at blocking additional package managers is so easily overridden by means of a trivial browser extension like paket-attacket (which is a terrible name). For what it's worth, the new NuGet Gallery, while it looks nice, is still only useful to me as a means of looking up versions and their related dependencies when things go sideways (i.e. Google's packages). I don't know anyone who uses the NuGet Gallery to figure out how to install a package. However, I imagine the installation instructions being useful to newer employees using NuGet for the first time. They are not going to care about any one-sided decisions you may have made if their employer uses paket or another third-party client. They will just be left confused and unable to use your site or worse, get themselves in some trouble for using the wrong tool.

The most worthwhile point I've seen hasn't come from the Microsoft team but by commentors: adding additional clients could eventually become a problem due to space constraints. I would assume that would be a good problem to have. I personally have no idea why anyone would care about whose client is used. They are just tools. The best news is that everyone is happy with the NuGet package system. I remember the package manager confusion several years ago (as well as how Microsoft poorly handled that situation with the community). This is definitely not that. You actually have community members trying to work with you.

@yawaramin

This comment has been minimized.

Show comment
Hide comment
@yawaramin

yawaramin Aug 7, 2017

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more ... What is the objective criteria we can use here to triage requests?

I think the simple criterion here is ... has any other third-party client made such a request? Because, really, I highly doubt that you'll be getting requests from every Tom, Dick and Harry NuGet client to appear on the website. It takes a lot of effort for a package manager to get to the point that people feel comfortable with asking MS to even mention it ... and Paket has somehow reached that point. IMO, that effort shouldn't be squashed with a ton of 'what if' scenarios.

yawaramin commented Aug 7, 2017

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more ... What is the objective criteria we can use here to triage requests?

I think the simple criterion here is ... has any other third-party client made such a request? Because, really, I highly doubt that you'll be getting requests from every Tom, Dick and Harry NuGet client to appear on the website. It takes a lot of effort for a package manager to get to the point that people feel comfortable with asking MS to even mention it ... and Paket has somehow reached that point. IMO, that effort shouldn't be squashed with a ton of 'what if' scenarios.

@skofman1 skofman1 added the Discussions label Aug 9, 2017

@jeremycook

This comment has been minimized.

Show comment
Hide comment
@jeremycook

jeremycook Aug 9, 2017

In the interest of defining criteria for listing clients on NuGet.org’s package details page.

There are GitHub stars. Getting more than a handful of stars is no small feat hard. Pick a number, any number.

Libraries.io has a metric called "SourceRank." Paket's current score is 12. Nuget.Client's score is 15, and for perspective, NPM's score is 25.

And I'm sure there are plenty of other sites that score open source projects, and provide a quick glance into a project's health.

It seems like the primary concern should be project health today and into the future. The SourceRank break down makes it easy to see where a project may have weaknesses that need addressed. In the event the NuGet team wanted to push back on a particular client, the team could provide specific goals for said client to overcome. For example: "Your NuGet client currently has only one contributor listed on GitHub. Please increase project involvement, and check in with us again in a few months."

(Aside, Paket is clearly one of those successful projects that wouldn't be questioned based on criteria like this. But the above is something that could give the NuGet team permission to let some in and provide grounds to dismiss others until their project grows to a sufficient size.)

jeremycook commented Aug 9, 2017

In the interest of defining criteria for listing clients on NuGet.org’s package details page.

There are GitHub stars. Getting more than a handful of stars is no small feat hard. Pick a number, any number.

Libraries.io has a metric called "SourceRank." Paket's current score is 12. Nuget.Client's score is 15, and for perspective, NPM's score is 25.

And I'm sure there are plenty of other sites that score open source projects, and provide a quick glance into a project's health.

It seems like the primary concern should be project health today and into the future. The SourceRank break down makes it easy to see where a project may have weaknesses that need addressed. In the event the NuGet team wanted to push back on a particular client, the team could provide specific goals for said client to overcome. For example: "Your NuGet client currently has only one contributor listed on GitHub. Please increase project involvement, and check in with us again in a few months."

(Aside, Paket is clearly one of those successful projects that wouldn't be questioned based on criteria like this. But the above is something that could give the NuGet team permission to let some in and provide grounds to dismiss others until their project grows to a sufficient size.)

@jeremycook

This comment has been minimized.

Show comment
Hide comment
@jeremycook

jeremycook Aug 9, 2017

Let's be honest, space is not an issue today. It will be an issue when there are a sufficient number of clients, but how that is handled is not a problem that needs solved today. For the moment there is plenty of space. Plus the visuals should primarily be the problem of your resident designer (not some committee of coders). Please shelve that reason to hold the horses.

jeremycook commented Aug 9, 2017

Let's be honest, space is not an issue today. It will be an issue when there are a sufficient number of clients, but how that is handled is not a problem that needs solved today. For the moment there is plenty of space. Plus the visuals should primarily be the problem of your resident designer (not some committee of coders). Please shelve that reason to hold the horses.

@jeremycook

This comment has been minimized.

Show comment
Hide comment
@jeremycook

jeremycook Aug 9, 2017

I do think providing a link to a little more information about each client is worthwhile. That information should include a brief description and a link to the client's project page, and could include a "NuGet does not support, endorse, etc." disclaimer as applicable. That information could be a page hosted on NuGet.org, a little popover, or a modal (I noticed you are using Bootstrap, easy). Here's a screenshot of a new Paket tab with a little question mark that would open the page/popover/modal. This little question mark and corresponding information seems like it would even benefit the first party clients. Not everyone know what the Package Manager Console is or how to get to it in VS.

jeremycook commented Aug 9, 2017

I do think providing a link to a little more information about each client is worthwhile. That information should include a brief description and a link to the client's project page, and could include a "NuGet does not support, endorse, etc." disclaimer as applicable. That information could be a page hosted on NuGet.org, a little popover, or a modal (I noticed you are using Bootstrap, easy). Here's a screenshot of a new Paket tab with a little question mark that would open the page/popover/modal. This little question mark and corresponding information seems like it would even benefit the first party clients. Not everyone know what the Package Manager Console is or how to get to it in VS.

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Aug 16, 2017

Having this as an issue is premature optimization.

Thorium commented Aug 16, 2017

Having this as an issue is premature optimization.

@pmbanka

This comment has been minimized.

Show comment
Hide comment
@pmbanka

pmbanka Aug 22, 2017

Hi @unniravindranathan, a lot of good ideas and comments were added to this thread since you last commented on the issue. Could you please give us an update on the current position of the NuGet team on what (if any) should the criteria be for listing clients on NuGet.org’s package details page?

pmbanka commented Aug 22, 2017

Hi @unniravindranathan, a lot of good ideas and comments were added to this thread since you last commented on the issue. Could you please give us an update on the current position of the NuGet team on what (if any) should the criteria be for listing clients on NuGet.org’s package details page?

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Aug 23, 2017

Member

First of all, thanks to everyone who participated in this discussion. Here is update from the NuGet team:

We believe that having multiple clients listed on the package details page will have a positive impact on the .NET eco-system. However, we also want to ensure the promoted clients match our customer’s expectation, which includes being secure & being actively maintained. We also want to avoid a situation where we the list of clients is becoming unwieldy. Hence, we believe that it is important that we agree on the set of criteria for listing clients on NuGet.org.

Now that we are done with the major releases from the week before, we took the feedback on this thread, as well as our own, and distilled it down into a proposal that I would like to discuss with you:

We will list clients on NuGet.org that meet the following criteria:

  • Significant adoption in .NET community: The client should have significant adoption within the .NET community. This can be proven in a number of ways, such as:
    • Demonstrated usage of the client in a large number of .NET projects.
    • Client usage for downloading top packages from NuGet.org. As an example, see the set of clients downloading Newtonsoft.Json
  • Actively maintained and updated: The client should be actively maintained and regularly updated to respond to NuGet's changing protocols and users' feedback. This can be proven in a numbers of ways, such as
    • Frequent GitHub contributions
    • Frequency of client updates published to common download endpoints such as NuGet.org or the Visual Studio Gallery
  • Security compliance: The client should be compliant with the latest security requirements as implemented by NuGet.org. The NuGet.org team will publish these requirements, as well as the roadmap required for compliance. Later this week, we will articulate the mechanism we will be using for communicating these requirements.
     
    Once listed, a client will be notified if it fails to satisfy one or more of the criteria mentioned above. Non-compliance with the notification will result in the client being removed from the listing.

The following is proposed experience for the listing:

  • A client will be shown as a separate tab on NuGet.org package details page as shown below:
    thirdpartyclientsonpackagedetailspage
  • We will add a hyperlink in the info message that can guide users to the respective tool's support page. For package consumers, the link can help to go to the right place to get more information, support and report issues. For the tool owners/maintainers this will ensure that their customers have a way to reach out to them and thereby creates additional channel to get feedback.
  • If there ends up being more clients than fits in the real-estate available, we will revisit the design for the listing at that point in time.
     
    Based on the above criteria, we feel that we are ready to add Paket once the appropriate metadata has been added to the PR and the UI work has been completed. We will soon be starting work on making the UI changes above as tracked by #4589.
     
    In general, if your tool meets the criteria as listed above, please create a new issue to add your tool to the package details page with the relevant information as called out above. Alternatively, if you want to discuss specific details about your client, please feel free to send me an email.
Member

anangaur commented Aug 23, 2017

First of all, thanks to everyone who participated in this discussion. Here is update from the NuGet team:

We believe that having multiple clients listed on the package details page will have a positive impact on the .NET eco-system. However, we also want to ensure the promoted clients match our customer’s expectation, which includes being secure & being actively maintained. We also want to avoid a situation where we the list of clients is becoming unwieldy. Hence, we believe that it is important that we agree on the set of criteria for listing clients on NuGet.org.

Now that we are done with the major releases from the week before, we took the feedback on this thread, as well as our own, and distilled it down into a proposal that I would like to discuss with you:

We will list clients on NuGet.org that meet the following criteria:

  • Significant adoption in .NET community: The client should have significant adoption within the .NET community. This can be proven in a number of ways, such as:
    • Demonstrated usage of the client in a large number of .NET projects.
    • Client usage for downloading top packages from NuGet.org. As an example, see the set of clients downloading Newtonsoft.Json
  • Actively maintained and updated: The client should be actively maintained and regularly updated to respond to NuGet's changing protocols and users' feedback. This can be proven in a numbers of ways, such as
    • Frequent GitHub contributions
    • Frequency of client updates published to common download endpoints such as NuGet.org or the Visual Studio Gallery
  • Security compliance: The client should be compliant with the latest security requirements as implemented by NuGet.org. The NuGet.org team will publish these requirements, as well as the roadmap required for compliance. Later this week, we will articulate the mechanism we will be using for communicating these requirements.
     
    Once listed, a client will be notified if it fails to satisfy one or more of the criteria mentioned above. Non-compliance with the notification will result in the client being removed from the listing.

The following is proposed experience for the listing:

  • A client will be shown as a separate tab on NuGet.org package details page as shown below:
    thirdpartyclientsonpackagedetailspage
  • We will add a hyperlink in the info message that can guide users to the respective tool's support page. For package consumers, the link can help to go to the right place to get more information, support and report issues. For the tool owners/maintainers this will ensure that their customers have a way to reach out to them and thereby creates additional channel to get feedback.
  • If there ends up being more clients than fits in the real-estate available, we will revisit the design for the listing at that point in time.
     
    Based on the above criteria, we feel that we are ready to add Paket once the appropriate metadata has been added to the PR and the UI work has been completed. We will soon be starting work on making the UI changes above as tracked by #4589.
     
    In general, if your tool meets the criteria as listed above, please create a new issue to add your tool to the package details page with the relevant information as called out above. Alternatively, if you want to discuss specific details about your client, please feel free to send me an email.
@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Aug 24, 2017

Contributor

This is a good step forward, and looks good to see. Once the UI changes are completed, can you add a comment or something to #4437 so it's clear what changes need to be made?

Thanks!

Contributor

isaacabraham commented Aug 24, 2017

This is a good step forward, and looks good to see. Once the UI changes are completed, can you add a comment or something to #4437 so it's clear what changes need to be made?

Thanks!

@WilliamOckham

This comment has been minimized.

Show comment
Hide comment
@WilliamOckham

WilliamOckham Aug 24, 2017

I have a few questions about this part:

Security compliance: The client should be compliant with the latest security requirements as implemented by NuGet.org. The NuGet.org team will publish these requirements, as well as the roadmap required for compliance. Later this week, we will articulate the mechanism we will be using for communicating these requirements.

Will the NuGet community have input into these security requirements? If not, why not?
Will the motivation and reasoning behind the requirements be communicated (in addition to the requirements themselves)?

WilliamOckham commented Aug 24, 2017

I have a few questions about this part:

Security compliance: The client should be compliant with the latest security requirements as implemented by NuGet.org. The NuGet.org team will publish these requirements, as well as the roadmap required for compliance. Later this week, we will articulate the mechanism we will be using for communicating these requirements.

Will the NuGet community have input into these security requirements? If not, why not?
Will the motivation and reasoning behind the requirements be communicated (in addition to the requirements themselves)?

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Aug 24, 2017

Member

This is a good step forward, and looks good to see. Once the UI changes are completed, can you add a comment or something to #4437 so it's clear what changes need to be made?

@isaacabraham Will do.

Will the NuGet community have input into these security requirements? If not, why not?
Will the motivation and reasoning behind the requirements be communicated (in addition to the requirements themselves)?

@WilliamOckham We do plan to announce such new requirements before we start implementing them. We have already laid out our roadmap as part of this blog post that lists out many features focused on security. Though many of those specs have just been incubated but as we make progress on them, we will add as much information there as needed, to explain the motivation and reasoning behind those features.

Member

anangaur commented Aug 24, 2017

This is a good step forward, and looks good to see. Once the UI changes are completed, can you add a comment or something to #4437 so it's clear what changes need to be made?

@isaacabraham Will do.

Will the NuGet community have input into these security requirements? If not, why not?
Will the motivation and reasoning behind the requirements be communicated (in addition to the requirements themselves)?

@WilliamOckham We do plan to announce such new requirements before we start implementing them. We have already laid out our roadmap as part of this blog post that lists out many features focused on security. Though many of those specs have just been incubated but as we make progress on them, we will add as much information there as needed, to explain the motivation and reasoning behind those features.

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Sep 8, 2017

Member

Update: The required changes to enable third-party tabs is done now. Hence I am closing this issue. I will also be commenting on the original PR:#4437 request so that new changes can be done and merged to enable Paket tab.

Please refer to the associated PR on the issue: #4589 to understand the changes required to enable third-party clients.

Member

anangaur commented Sep 8, 2017

Update: The required changes to enable third-party tabs is done now. Hence I am closing this issue. I will also be commenting on the original PR:#4437 request so that new changes can be done and merged to enable Paket tab.

Please refer to the associated PR on the issue: #4589 to understand the changes required to enable third-party clients.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment