How do we prevent Addin's becoming stale? #1136

Closed
gep13 opened this Issue Aug 5, 2016 · 25 comments

Projects

None yet

10 participants

@gep13
Member
gep13 commented Aug 5, 2016

A question was asked on Gitter here where:

@geertvanhorrik said...
Thanks @patriksvensson . I was just wondering how you deal with this. Maybe it's good to ask community people to contribute to a centralized repository so others can take over if need be?

This was basically in response to an attempt that was being made to change an existing Cake Addin, when the maintainer of said Addin seemed to be not available. In this particular example, the maintainer came back very quickly, and the issue was resolved, but it does raise the question about what happens when a maintainer does step away from an Addin, what do we do?

What follows is my recommendations for how to deal with this situation (based on conversations with @devlead @patriksvensson and @redth) and I was hoping to get some feedback from the wider community on how to proceed.

Example Situation that we want to avoid

The imagine the following situation as our example...

A Cake Community Member creates a new addin for Cake (hosting the code in his/her own repository), then pushes it to NuGet.org using their own account. Life then gets in the way, and that maintainer of the package isn't able to respond to issues, pull requests, any more. Another community member takes it upon themselves to fork the repo, implement the required changes and suggestions, and pushes essentially a duplicate package to NuGet.org

What is wrong with this from a maintainability stand point

  • Essentially duplicate packages on NuGet.org, so people are not sure which one to use
  • Duplicate code bases, again, which one should be used

Possible solutions to this problem

  • The creator of the original addin could make other people contributors/owners of the repo in question, and essentially allow them to take over the package
  • The creator of the original addin could add additional maintainers to the package on NuGet.org

Both of these solutions would fix both of the issues mentioned above, however, I am not sure if it goes far enough. Both of these solutions would require after the fact changes to allow people access to both the repo and NuGet.org. Both of which might not be possible. i.e. if the original maintainer isn't responding to issues/pr's, they might not be available to provide access to the systems either.

A potential solution

I am going to suggest that we create a new Organisation on GitHub (let's call it Cake-Contrib). We would invite all existing Addin creators (and obviously new addin creators) to put their Addin Repositories into this organisation. Within the organisation we would create a team for each addin. This team would consist of all Core Cake Team members as well as the addin creator. This team would have full access to the repo once under the organisation.

In addition, the addin creator would add the cake-build NuGet user as a co-maintainer of the package on NuGet.org.

With these two things in place, we solve both the problems described above.

  • Code is always in one place, and if issues/pr's are starting to get missed the Cake Core Team members to step in to help out
  • The cake-build NuGet user has access to push a new version of the package, no again, no duplicates

Following on from this, I would see other teams being added to the Cake-Contrib repo. These would be teams of trusted Addin Creators, who are given access to repos other than their own, as they have proven to be very good at what they do, and can help out where necessary.

Important points

  • The original addin creator would still have full access to the repo under the new organisation
  • They would still be responsible for the day to day maintenance of the addin. Other team members would only step in when things aren't being dealt with

Minimum things to be included in order to get acceptance into organisation

  • Documentation for Addin
  • Unit Tests
  • CI builds
  • Anything else?

Idea that was suggested and discarded

A single repository which housed all the addins. This was discarded as it didn't allow enough control over who has access to individual sections of the repo. i.e. there are no folder based permissions in GitHub. As a result, the security control wasn't granular enough.

@gep13 gep13 added the Question label Aug 5, 2016
@daveaglick
Collaborator

I'm not a huge fan of the proposed approach, primarily because I can see it having an impact on the addins I maintain (Wyam and Scripty) and can envision other addin authors with the same problem. In my situation, I find a lot of value in having the addin projects in the same solution as the projects to which they're related. This more easily lets me ensure the addin stays consistent with changes to the underlying projects, especially when doing automated refactoring. Keeping the Cake addins in the same solution obviously becomes much more challenging if the code needs to be in a different repository.

My specific concerns aside, I'm also not sure how viable this sort of solution would be. At most, the Cake organization could request (or strongly encourage) that addin authors place their addin code in the official contributions repository. That'll probably cover many, but I'm guessing there will still be holdouts.

I'll offer an alternate idea. If the underlying concern is over identification of "approved", "well known", or "well maintained" addins, could an official list of such addins be maintained? Addin authors could keep this list updated with PRs, and the Cake team members could also remove or replace stale addins as needed. Cake could check the list when downloading addins from NuGet (or other sources) and display a warning when an addin is either not on the list or has been superseded by a more up to date addin (such as the forking case).

@daveaglick
Collaborator

In reply to a comment on Gitter about loosing access to the addin repository if it's not added to a common organization: wouldn't we have that problem anyway? If the author is pro-OSS, the repo will be on GitHub or something and can be forked. If not, they're not likely to add the code to the common repo anyway. I'm not sure how either approach resolves the case where the addin author doesn't release their code.

(I'm traveling today so want to get my thoughts in before possibly loosing access)

@luisgoncalves
Contributor

I tend to agree with the solution but I think we could wait and see if there are more (problematic) examples and if they fit. The status list approach is also valid, but I think it offers less guarantees and doesn't avoid some possible noise around multiple packages/repos.

@devlead
Member
devlead commented Aug 5, 2016

@daveaglick interesting thoughts, wonder what the criteria for a stale addin would be?
Simpler addins might essentially be "done", personally I think the main concern for any oss repo is how issues and prs are attended. That said we can't expect a one person project to offer 24/7 instant feedback, on occasion people do seem to have unreasonable expectations on OSS authors.
Obviously not being compatible with the latest version Cake would of course be considered stale.

@SharpeRAD
Contributor

I'm not against adding the 🍰 team as contributors to my repositories if you ever feel like I'm slacking but I like the fact that their my repositories, under my account and you can't impose your style cop rules on me 😄

@luisgoncalves
Contributor

@SharpeRAD eheh but that's a very valid point; which rules would apply to the contrib repo? :)

@SharpeRAD
Contributor

The point of OSS is there are no rules! You contribute on your own time, in your own way.

@patriksvensson
Member

@SharpeRAD @luisgoncalves We would not impose Cake's style guide for addins owned by the community in any way. We might want to make sure that there are CI for the addins and reasonable amount of unit/integration tests, but code style we wouldn't.

@patriksvensson
Member

@SharpeRAD @luisgoncalves @daveaglick Also important to remember that we wouldn't require addins to be under the Cake-Contrib organization. This would be an opt-in thing 😄

@devlead
Member
devlead commented Aug 5, 2016

@daveaglick and agree forking is an option, don't main issue is GitHub, but actually NuGet, if an author of an package goes totally dark it can cause confusion, what ID should fork use, of course Cake web can have an curated list, but many might just search for Cake on nuget and stumble on obsolete addin i.e.

@daveaglick
Collaborator
daveaglick commented Aug 5, 2016 edited

many might just search for Cake on nuget and stumble on obsolete addin

That's why a warning (though not a failure) would be helpful when a "stale" addin is installed or used.

I'm actually softening my opinion a little too. I can see this proposal working well for more general addins (like file IO) or for addins that address very broad or popular libraries like AWS. A community repo with editing permissions for core team members would certainly help keep those up to date.

I wonder if a combination of both approaches is worth considering. Addin authors could "opt-in" to place their addin under Cake organization control if they feel it's appropriate, and the list serves as a check for all addins, both in the community repo and not.

I could even see the list eventually being partially automated. For example, by searching NuGet and seeing if addins are compatible with latest version, etc.

@devlead
Member
devlead commented Aug 5, 2016

As @patriksvensson stated, this would be totally opt in and we just wanted as people have raised concerns start a discussion to get a feel for what the community thinks. Is it an issue? What could be a good solution? Could the right solution be a combination of solutions? Case by case?
Love that a few people already jumped in the discussion 👍

@GeertvanHorrik

I think the cake addin repository shouldn't be the next npm (with tons and tons of abandoned packages). I think every developer would be ok with putting their code on a centralized repository if:

  1. They are the owner of the stuff
  2. Don't enforce code rules, development processes or anything on them (except that there is a general admin that can take over in case someone (accidentally or not) abandons an addin
  3. You can provide them with a template for a new addin (with build scripts and all that kind of stuff). This could also have a positive effect on the number of addins being pushed to the public. Currently people might just create their own private stuff and don't care about other people

Keeping an additional list with "stale" addins is additional maintenance and then there must be a document with rules to determine what makes an addin stale. If you put it in a centralized organization on GitHub, multiple admins are at least noticing stuff going on in repositories making it easier to detect abandoned repositories.

Of course it's hard to enforce stuff like this, but at least it's something you can discuss with the addin developers (personally I wouldn't mind this at all if I was an addin developer).

@Redth
Contributor
Redth commented Aug 6, 2016

I thought about this a bit more and I tend to agree with the idea that I like to maintain the source code under my name on GitHub since I made the add-in to begin with. Having said that I'd be open to moving some more popular ones into the cake org (like Cake.Json or Cake.FileHelpers which arguably could be part of cake core). But mostly there's some sense of ownership and satisfaction having it under my own name.

The worry is stale addins. Stale repos isn't really the worst issue. Code can always be forked to be updated (even if not ideal).

The real issue is nuget package ownership. Forking and releasing multiple versions of the same package on nuget under different owners in my opinion is the worst problem we are trying to solve. Moving source code under a cake org doesn't solve this problem.

Trying to get people to proactively move their code over is as much of an effort as trying to proactively have them add cake as an owner to the nuget package.

My current view is that you should be trying to proactively get people to add cake as nuget package owners and maybe even GitHub committers which I think will solve the issue.

I still think it's a nice idea to give the option of moving repos under a cake org.

Finally I like the idea of maintaining a list of active and perhaps even stale addins (or at least addins where cake has no nuget ownership of).

@agc93
Member
agc93 commented Aug 6, 2016

I'd agree with @Redth and @daveaglick : I would prefer to maintain my addins in my own repos, as some of them are related to larger solutions, and I can maintain my code exactly as I like.

There's certainly value in perhaps adding the Cake org as a package owner (as @Redth mentioned), but I have also found that the .NET OSS community is also very quick to cry "stale" so we should be careful how we approach this.

As an additional idea for the "official addin list", I'm thinking apply the same criteria @gep13 mentioned (must have doco, must have CI) to inclusion in the website addin list, and use that as the official source of truth?

Also just noticed @daveaglick 's proposal for a "core" addin org, which I like as an idea, but raises a lot of questions of what would be included, and is there any difference from a consumer or support point of view on third-party addins from a "core" repo and third-party addins from some other repo?

@gep13
Member
gep13 commented Aug 6, 2016

Oh wow, that is a lot of comments! Which is great news, very glad to see people with an interest in discussing this. Let me try to address some of the comments.

@daveaglick said...
In my situation, I find a lot of value in having the addin projects in the same solution as the projects to which they're related.

Absolutely. I never envisioned all addin's making their way into this organisation. In cases like Wyam, Scripty, and MagicChunks, it makes complete sense for these addin's to remain with the application that they are providing a wrapping for in Cake.

@daveaglick said...
At most, the Cake organization could request (or strongly encourage) that addin authors place their addin code in the official contributions repository. That'll probably cover many, but I'm guessing there will still be holdouts.

Again, agreed. As I think @patriksvensson and @devlead have stated, what is being suggested here is completely opt-in. Even if we wanted to, we couldn't force someone to move their repository under this suggested organisation.

@daveaglick said...
I'll offer an alternate idea. If the underlying concern is over identification of "approved", "well known", or "well maintained" addins, could an official list of such addins be maintained?

This isn't the main reason for this suggestion, although it is an important consideration. It is more about a pro-active way to both help and support addin maintainers in the long term.

@daveaglick said...
Addin authors could keep this list updated with PRs, and the Cake team members could also remove or replace stale addins as needed. Cake could check the list when downloading addins from NuGet (or other sources) and display a warning when an addin is either not on the list or has been superseded by a more up to date addin (such as the forking case).

Although it doesn't cover everything that you have described, this is essentially what we have here, right?

@daveaglick said...
In reply to a comment on Gitter about loosing access to the addin repository if it's not added to a common organization: wouldn't we have that problem anyway? If the author is pro-OSS, the repo will be on GitHub or something and can be forked. If not, they're not likely to add the code to the common repo anyway. I'm not sure how either approach resolves the case where the addin author doesn't release their code.

To be 100% clear, I wasn't suggesting that anyone who has taken their time to create an addin for Cake would lose anything in the approach that I suggested above. They would still have complete control over the repository, the direction that the addin was being developed, features and functions that they wanted to be included in it, etc. We are not trying to mandate anything here, this was a suggestion that would allow the Core Cake Team to step in to help, IF a situation arose where an addin had become stale, and help was required. By having that access up front, rather than when the problem arose would save a lot of hassle for everyone involved.

@luisgoncalves said...
I tend to agree with the solution but I think we could wait and see if there are more (problematic) examples and if they fit.

I tend to think that the wait and see approach might not be the correct course of action, as it might well be too late by then. I could be worrying unnecessarily here though 😄

@SharpeRAD said...
I'm not against adding the 🍰 team as contributors to my repositories if you ever feel like I'm slacking but I like the fact that their my repositories, under my account and you can't impose your style cop rules on me 😄

As I think @patriksvensson mentioned, this certainly wouldn't happen. This suggestion is NOT about mandating the Styling, Coding Conventions, etc that is being used for each addin. We are humbled and grateful that you all as package maintainers have created all the addin's that you have, and we are certainly not trying to impact on any development efforts that you have.

@luisgoncalves said...
@SharpeRAD eheh but that's a very valid point; which rules would apply to the contrib repo? :)

Bottom line, nothing at the minute. This is completely up in the air, and if we go ahead with any solution this would be based on community feedback. From a personal stand point, I would like to see documentation for aliases (with examples), and a CI build in place. Unit tests would also be a "nice to have" but not a blocker to entry.

@SharpeRAD said...
The point of OSS is there are no rules! You contribute on your own time, in your own way.

I am in 100% agreement with this statement. What I will say though is, I have been in a number of situations where I have begun to feel a sense to "psychic weight" bearing down on me when I haven't been able to respond to issues/pull requests/questions, on projects that I have been working on. The suggestion above stemmed from a point of view of wanting to prevent this happening to other people. To know that someone else "can" help out on a project if/when required, personally, provides me with a lot of comfort.

@daveaglick said...
I wonder if a combination of both approaches is worth considering. Addin authors could "opt-in" to place their addin under Cake organization control if they feel it's appropriate, and the list serves as a check for all addins, both in the community repo and not.

Yes, I could see that approach working well.

@GeertvanHorrik said...
You can provide them with a template for a new addin (with build scripts and all that kind of stuff). This could also have a positive effect on the number of addins being pushed to the public. Currently people might just create their own private stuff and don't care about other people

This is actually being worked on by @agc93 in the form of a Cake Addin Project Template for his Cake.VisualStudio Extension 😄

@Redth said...
I thought about this a bit more and I tend to agree with the idea that I like to maintain the source code under my name on GitHub since I made the add-in to begin with. Having said that I'd be open to moving some more popular ones into the cake org (like Cake.Json or Cake.FileHelpers which arguably could be part of cake core). But mostly there's some sense of ownership and satisfaction having it under my own name.

I totally take this point onboard, and I can see why this would be important to people. Again, this is not something that we are mandating, but rather if we go ahead with it, it would be opt-in, and the original addin creator would still have FULL access to the repository, and would be a member of the organisation on GitHub.

@Redth said...
The real issue is nuget package ownership. Forking and releasing multiple versions of the same package on nuget under different owners in my opinion is the worst problem we are trying to solve. Moving source code under a cake org doesn't solve this problem.

@Redth said...
My current view is that you should be trying to proactively get people to add cake as nuget package owners and maybe even GitHub committers which I think will solve the issue.

Yes, I totally agree with this.

@agc93 said...
Also just noticed @daveaglick 's proposal for a "core" addin org, which I like as an idea, but raises a lot of questions of what would be included, and is there any difference from a consumer or support point of view on third-party addins from a "core" repo and third-party addins from some other repo?

Hmm, I will have to think about this one. Not sure. What are other's thoughts on this?

@ghuntley
Contributor
ghuntley commented Aug 9, 2016 edited

I've created a few over the last couple months - +1 on working on initiatives to preventing addin's from becoming stale. General gist is - if you send in a quality PR - then I'll grant you push access to the repo, then it's just a single click to promote from myget to nuget. ie. minimal friction on my part/simple as replying to a tweet - etc. Sorry for the short reply - don't have time to properly digest this entire thread ATM.

@gep13
Member
gep13 commented Aug 9, 2016

@daveaglick @luisgoncalves @SharpeRAD @GeertvanHorrik @Redth @agc93 did you guys see my response to your comments above? Did these help to clarify the suggestion? Any other comments that you would like to share?

@ghuntley thank you for your feedback, appreciate it. The main stumbling block I still see with that approach is that it is still a reactive move. The main premise of what I am suggesting is that it is proactive. Access is given proactively to the cake-build user on NuGet and ideally on the repo so that if (and only if) intervention is needed/required, this can happen without having the reach out to people when they are not available.

@agc93
Member
agc93 commented Aug 9, 2016

I think the suggestion is pretty clear at this point, the issue is agreement 😆 I don't mind the concept, but am not 100% convinced.

One thing I have noticed in .NET (that I mentioned above) is that people do seem very quick to call something "stale". They see last commit being 6+ months ago and assume the author is long gone when in reality, they just didn't have any new features to implement and as @ghuntley pointed out, are ready and willing to accept contributions.

I also find it a bit odd that we would then have the problem of the full addin list, the DSL documentation, any proposed list or core repo, and just quickly searching for something on GitHub returning 4 different lists of addins.

Maybe make the proactive approach available as a proactive option for authors to say "yeah, I'm done with this, don't care from here"? Just a thought.

Happy to be corrected by the much more experienced hands around here..

@gep13
Member
gep13 commented Aug 9, 2016

@agc93 said...
I also find it a bit odd that we would then have the problem of the full addin list, the DSL documentation, any proposed list or core repo, and just quickly searching for something on GitHub returning 4 different lists of addins.

Sorry, I think I have missed something here, not sure I follow what you are getting at.

@agc93
Member
agc93 commented Aug 9, 2016 edited

If we implement a "core" addin repo as @daveaglick suggested (and I think someone mentioned), you add another list of addins. Now, to answer the question of "is there an addin for <x>", a user would need to:

  1. Check if anything relevant is in the DSL page (hypothetically no)
  2. Check the addin list on the website (note that this picks up additional ones like AliaSql)
  3. Check the "core" repo if it existed
  4. Just search on GitHub (this obviously picks up non-complete ones like Tfx)

Just my $0.02, but it seems like we should be thinning that list, not adding another one

EDIT: In hindsight, somewhat of tangential issue, so probably not too relevant to this issue

@gep13
Member
gep13 commented Aug 9, 2016

@agc93 okay, I see what you are saying now. Thank you for the the clarification.

@luisgoncalves
Contributor

@gep13 yes, it clarified. I think keeping the opt-in effort to a minimum is important. Even if some things are missing (a few docs, tests, etc) from the moment the addin is on the org, it's likely going to be faster to get those from the community. Not much more to add a this point :)

@gep13
Member
gep13 commented Aug 9, 2016

@luisgoncalves said...
Even if some things are missing (a few docs, tests, etc) from the moment the addin is on the org, it's likely going to be faster to get those from the community.

Yes, that is a good point.

@gep13
Member
gep13 commented Sep 1, 2016

@daveaglick @luisgoncalves @SharpeRAD @GeertvanHorrik @Redth @agc93 @ghuntley once again, thank you all for the conversation that was had in this issue. The @cake-build/team have discussed it, and the outcome of that discussion has been captured in this blog post:

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

Please let us know if you have any feedback about the plans going forward. Thanks!

@gep13 gep13 closed this Sep 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment