How do we prevent Addin's becoming stale? #1136
Comments
|
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). |
|
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) |
|
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. |
|
@daveaglick interesting thoughts, wonder what the criteria for a stale addin would be? |
|
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 😄 |
|
@SharpeRAD eheh but that's a very valid point; which rules would apply to the contrib repo? :) |
|
The point of OSS is there are no rules! You contribute on your own time, in your own way. |
|
@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. |
|
@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 😄 |
|
@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. |
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. |
|
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? |
|
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:
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). |
|
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). |
|
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? |
|
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.
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.
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.
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.
Although it doesn't cover everything that you have described, this is essentially what we have here, right?
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.
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 😄
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.
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.
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.
Yes, I could see that approach working well.
This is actually being worked on by @agc93 in the form of a Cake Addin Project Template for his Cake.VisualStudio Extension 😄
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.
Yes, I totally agree with this. @agc93 said... Hmm, I will have to think about this one. Not sure. What are other's thoughts on this? |
|
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. |
|
@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 |
|
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.. |
Sorry, I think I have missed something here, not sure I follow what you are getting at. |
|
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
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 |
|
@agc93 okay, I see what you are saying now. Thank you for the the clarification. |
|
@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 :) |
Yes, that is a good point. |
|
@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! |
A question was asked on Gitter here where:
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
Possible solutions to this problem
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.
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
Minimum things to be included in order to get acceptance into organisation
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.
The text was updated successfully, but these errors were encountered: