+1 to all of this. I honestly do not know the best way to go about this, I have limited experience in this area, but it was a hassle to say the least when I wanted to contribute to the foreman_banner plugin. I actually never ended up taking it over. Basically the process was me forking, making changes, opening a PR (pretty standard). Then after a few days trying to hunt down the owner through MANY difference means of communication. By the end of it, they would not transfer ownership of the project to me but rather merged my PR and released a new Gem. I would assume that after that it basically went back to being unmaintained. All in all I would say the entire process took almost a month.
Again, I do not know the best way, or even a way to solve for this but I'll take anything. I would have loved to take over that plugin and keep developing upon it. On Tuesday, July 18, 2017 at 7:15:26 AM UTC-4, Greg Sutcliffe wrote: > > Hi all, > > I've been thinking for a while about plugins, and how to continue them > when original authors move on. It's only natural that developers will > come and go, so we need to think about how to deal with this. We've got > a few examples of this now, and have had others in the past. > > 1) I'm playing with Salt in my spare time at the moment, with a view to > (maybe) taking on the foreman_salt plugin, since Stephen is no longer > working on it. However, it's only chance that I know this fact - > there's no easy way for an author to mark a plugin as "orphaned". > > 2) Some plugins are awaiting changes but the author hasn't responded > (yet!). Foreman_bootdisk has some open PRs at the moment that fall into > this category (PRs 42, 43 for example), and default_hostgroup has pen > issues (oops!). Presumably we need a way to ping authors and find out > if they're just AFK or have stepped away from the plugin entirely. > > 3) Some plugins are definitely abandoned. I recall Chris Pisano taking > over the foreman_banner plugin last year and struggling to get in touch > with the original author at all. > > For context, Fedora does have a policy for this that makes some sense: > > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai > ners > > That's quite heavy, but some of the points make sense. So, do we need > to add something to our docs about this. My gut feeling is: > > * Yes, we do > * Only applies to plugins in "theforeman" GitHub repo > * We need to add extra maintainers to the Rubygems *before* the author > leaves - Chris had a real issue here. This could be a requirement of > getting aplugin packaged, for example. > * We need to allow authors to "abandon" a plugin clearly (something > like how the Arch User Repository does it maybe?) > > Thoughts? > Greg > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
