search

nlowe / Cake.MiniCover

A Cake Addin for Minicover, making it as easy as possible to get cross-platform code coverage on dotnet core
https://cakebuild.net/dsl/minicover/
MIT License
4 stars 1 forks source link

Add cake-contrib user #1

Closed gep13 closed 6 years ago

gep13 commented 6 years ago

First of all, I wanted to thank you for adding to the Cake community by adding this addin.

I was just wondering if you had seen this blog post:

http://cakebuild.net/blog/2016/08/cake-contribution-organization

We are currently going through a process of increasing the visibility of addins, and also trying to ensure their long term maintainability.

To that end, we are asking addin creators to add the cake-contrib user on NuGet as a co-owner (this can be done through the NuGet website by clicking on Manage Owners on the package page).

Would you be interested in doing this? If you have any questions about this, please let me know. There was some initial concern that the Cake Team were trying to "take over" packages, and that couldn't be further from the truth, and if you have this concern, or others, I would like to address them.

Thanks!

nlowe commented 6 years ago

@gep13 I have not seen this. I'll take a look today. Thanks!

gep13 commented 6 years ago

@nlowe perfect. Please let me know if you have any questions.

nlowe commented 6 years ago

@gep13 Thanks again for opening this issue.

From what I understand the procedure outlined in the blog post you linked has two purposes:

  1. Increase visibility for community-contributed cake addins
  2. Give the cake team the ability to fork an addin and continue to publish it under the same package ID if the maintainer up and disappears or is no longer able to maintain the addin.

Do I have that right?

A few thoughts. On the first point, even though that blog post has been around since late 2016, I was unaware the cake-contrib org was a thing until very recently, so I'm not sure how much visibility this actually provides. I'm not opposed to moving this addin under that org, but I'd like to wait until the developer experience is where I'd like it to be (not having to ref a tools project, see lucaslorentz/minicover#31) before moving the repo.

As for adding the cake-contrib user as an owner on nuget.org, I can see how that's valuable if the addin resides under the cake-contrib org, but I'm a little hesitant to add another owner before the repo gets moved.

gep13 commented 6 years ago

@nlowe thanks for getting back to me. I wanted to try to address a couple points, in order to make sure that we are on the same page...

Increase visibility for community-contributed cake addins

Yes, this is certainly the intention. What I meant by this, is that in addition to looking at the list of addins which are present on the Cake website, people can all look at this list on NuGet.org:

https://www.nuget.org/profiles/cake-contrib

To get a list of the addins that exist for Cake.

Give the cake team the ability to fork an addin and continue to publish it under the same package ID if the maintainer up and disappears or is no longer able to maintain the addin.

Yes, this is what I would regard as the primary reason behind what I am describing. Let me give you an example...

One of our Cake Contributors created this package, and pushed it to NuGet.org:

https://www.nuget.org/packages/Cake.MSBuildTask/

The cake-contrib user was not a co-maintainer of the package on NuGet.org at the time. Now, fast-forward a couple of years, and unfortunately, the maintainer of that package sadly died. Another member of the Cake Community reached out to us because they were hoping to get the addin updated. Since we didn't have access to the NuGet Package, we had two options...

  1. We could create a new package id, that was similar to the original one, and point people towards that one. This, to me, is problematic, as it causes duplication, and makes it unclear which one should be used
  2. We could reach out to the NuGet Team to see if we could assume ownership of the package

We went with the latter and we were fortunate in the fact that the NuGet Team didn't have a precedence for this happening, and as a result, they made the cake-contrib user a co-maintainer of the package. Going forward, this won't happen as there are now rules in place for dealing with these situations, which include contacting the next of kin of a package, or having written agreements in place, etc. This is far from ideal, but I totally understand where the NuGet Team are coming from. As it is now though, we (the Cake Team) are able to push new package versions to this package, and we have forked the original repository in the cake-contrib organisation on GitHub in order to continue development. In order to avoid this situation happening again, whilst still allowing Cake Community members to be the primary maintainer of the package, we pre-emptively ask maintainers to add the cake-contrib user as a co-maintainer for their packages. This is on the understanding that we, the Cake Team, would never push a package version, unless explicitly told to by the maintainer. This approach means that we have a route that we can take to continue development, should the worst happen.

I'm not opposed to moving this addin under that org, but I'd like to wait until the developer experience is where I'd like it to be (not having to ref a tools project, see lucaslorentz/minicover#31) before moving the repo.

Notice, in all of the above situation that I described, I didn't mention moving the GitHub Repository into the cake-contrib organisation, and I did this quite specifically. This is certainly far from mandatory, and adding the cake-contribu user to the NuGet package, is not the same thing as moving it into the cake-contrib organisation, and the two things don't have to happen at the same time, or even at all. I would regard the movement in the cake-contrib organisation as a "nice to have", and the addition of the cake-contrib user on NuGet as a strong preference.

What I will say is that if you did choose to move the repository under the cake-contrib organisation, you would have FULL control over the development of the addin. We, the Cake Team, would not get involved at all, unless the maintainer requested some help.

As for adding the cake-contrib user as an owner on nuget.org, I can see how that's valuable if the addin resides under the cake-contrib org, but I'm a little hesitant to add another owner before the repo gets moved.

I am hoping that based on the description of the real problem that we faced, you can see why this can be quite an important thing.

Please let me know if you have any questions about this. I would be happy to jump on a call to discuss further if you wanted to.

nlowe commented 6 years ago

After consideration I've decided to add the cake-contrib user as an owner on nuget.org.

Notice, in all of the above situation that I described, I didn't mention moving the GitHub Repository into the cake-contrib organisation, and I did this quite specifically. This is certainly far from mandatory, and adding the cake-contribu user to the NuGet package, is not the same thing as moving it into the cake-contrib organisation, and the two things don't have to happen at the same time, or even at all. I would regard the movement in the cake-contrib organisation as a "nice to have", and the addition of the cake-contrib user on NuGet as a strong preference.

I understand and I appreciate the nuance. Perhaps I wasn't as clear as I thought: I understand that moving the project to the cake-contrib org isn't mandatory. I was trying to say that I feel it would be a good place for the addin but I'd like to clean it up a bit first.

Thanks again for the heads up, let me know if there's anything else I need to fix on the nuget.org side of things.

gep13 commented 6 years ago

@nlowe said... I was trying to say that I feel it would be a good place for the addin but I'd like to clean it up a bit first.

Totally understand. Feel free to reach out if/when you want to get it transferred.

Thank you for adding the cake-contrib user on NuGet.org. I have accepted the request.