Project seems unmaintained #953
Comments
|
a good presentation on the general problem: https://www.youtube.com/watch?v=e_-qV8waPVM maybe ask the maintainer on Twitter if they would be happy to let some fork become the canonical fork? |
|
Hi, thanks for expressing your concern. I won't speak for @technicalpickles much here, but I don't think he would mind if I said that it's true that he was the sole maintainer for a while and that lately he had difficulty allocating time to work on this project on the side. I wouldn't say that the situation is so grave, though. Last code change on 3rd of April shouldn't be an indication that a project is “dead” and everyone should immediately jump ship. Instead, you could give us the benefit of the doubt and assume that we know that we have a problem with resources right now and give us some breathing space to work it out before we continue. In the meantime, in the spirit of open source, everyone is free to continue submitting PRs, trying out patches from PRs, or even switching to forks that provide certain fixes/features. We definitely appreciate that. We will definitely consider your suggestion to seek help with maintenance. 👍 |
|
I think adding new maintainers would be great, but changing repo would reduce the visibility of this project so I'd prefer that Hubot stays in the Github organisation |
|
@sdimkov Thanks for keeping us honest. We are working on getting some more GitHubbers involved so all the maintenance doesn't just fall on one or two people. You should start to see more activity around here in the next few days. In the mean time, feel free to point out any pull requests or issues that blocking for you and we'll make reviewing them a priority. |
|
@bkeepers Thanks! I'm really glad to see that this project is now getting some more GitHub love. |
|
Tangential rant: This highlights a major error in GitHub's conceptual model for repos. There's a presumption that the initial authorship of a project is inherently superior. Say I've got a project like hubot and I want to see which fork is most active. I can't just click and get a graph of which fork has the fastest time between receiving a PR and closing or merging it. Say that I have time to manage a hubot fork, and more time for it than GitHub itself has. Given that building a forks explorer (or whatever) hasn't been a priority for GitHub, I could do all that work, yet hubot's progress overall would still be a matter of when GitHub had time for it. For my fork to really matter, the canonical repo would either have to take a bunch of PRs from it, or manually redirect people to it with a line of text in the README. Otherwise the hubot world's splintered and the only way around its fragmentation is word of mouth. GitHub is centralized even though git is distributed. This is a semantic mismatch, but it's usually not a problem. Because GitHub's a great site. You get a lot of benefits by adding a center back to the model. But GitHub is also hierarchical even though git is flat. A completely flat, sprawling web of commits back and forth between forks is entirely possible within git. It would need no discernible center. But on GitHub, pull requests have to flow upwards to attain lasting impact. So a canonical repo is not intrinsically necessary to the git model. But if you want a canonical repo, and you're adding a center back to a decentralized technology, then it would make sense to put any canonical repo at a center. GitHub puts it at a top. TLDR:
|
|
@gilesbowkett Interesting point. How would you handle distribution of releases in this world where there isn't a canonical repository? NPM and almost every other package manager also has the concept of a canonical source. There is value in distribution of stable releases. It would be very difficult for something like hubot to exist in a world where package authors couldn't rely on a canonical version of the core. I understand your point and agree that a canonical repo is not necessary in git's model. However, source code is only one part of running a successful project and I think those other aspects would get very complicated without a canonical source. |
|
@gilesbowkett GitLab CEO here, I think it would be cool to make it easy for a fork to merge a PR aimed the canonical source and then leave a notice at this (still open) PR. This way forks do have the benefit of being able to merge contributions to the canonical repo and show people they are more active. And the ability to easily set another canonical source for your fork. What do you think? |
|
@bkeepers right, sorry, I thought I implied everything you said. +1 to that. the canonical repo is one of the worthwhile compromises imo. you add the center back to a decentralized thing, it's worth it to some degree. putting the repo at the top, instead of at the center, is where I think it's a problem. see the YouTube video I linked above. |
|
@dosire I think that would be great. in an ideal world there'd also be some kind of overview thing where you could look at a branch as a Venn diagram of PRs. or look at a project as a cluster of branches. a lot of great projects get half-abandoned, with downstream projects half-continuing development, and if you could see the community's engagement with a given project at a glance, the same way you can look at Issues or PRs and thereby spot the maintainer's degree of engagement at a glance, it would be much more useful for open source development, because open source is much more often about communities than about originators. |
|
@gilesbowkett @dosire @bkeepers this is an interesting discussion and all, but would you kindly to take it somewhere else that isn't a hubot issue? 😀 |
|
Sure, sorry. I'll move it to a blog. |
|
I had been pretty burned out on maintaining hubot, and it was starting to show. This issue was kind of the head of it for me, and ironically a plea for help made me feel even worse about the state of things. especially considering I still try to answer and merge pull requests, just not necessarily on the time scale people want or need. Hence my silence on here until now. After that, I was able to reach out to @bkeepers within GitHub, and start working through some of the feels and start taking steps to fix them. To be honest, the scope of hubot as it exists is pretty epic. There's different chat services to integrate with, different ways to persist your data, different ways to run and deploy your hubot, not to mention the infinite different ways anyone can be scripting their hubot and using community scripts. When someone is just starting out, there are so many ways they can have problems, and it takes time and a good eye for detail to suss out what specific problems a user is having. In addition, the core of hubot's functionality is pretty critical for us internally, so it can be pretty scary trusting other people to work on it. It's nearly impossible for any person to do all that, and I'm not sure even a small group would be able to manage it. After some planning, Friday was going to be the day to make a big push on getting hubot back into shape. Here is what we were able to get done:
I'm sure there was more, but most of this happened on Friday so it was hard to keep track 😁 @bkeepers pulled some stats together: Here are some stats on closed issues and PRs from Friday:
Given all that, I think we can confidently say that Hubot is maintained, and I'm feeling a lot better about things. Like any other project, it's always a work in progress, so we're trying to find other ways to make sure he stays that way. |
|
Massive 👏 to @technicalpickles and @bkeepers for their work last week (and over the last several years!). Every project has hiccups, and I couldn't ask for a better response. |
|
👏 👏 👏 👏 @technicalpickles and @bkeepers. Really happy to see this picking up again (and totally understood around maintenance cost). Looking forward to future work and merges! 👍 |
|
@technicalpickles hubot will live on without you. burnout is terrible. be good to yourself. it's supposed to just be a fun project anyway, if I understand correctly. that's certainly how I look at it. highly recommend the video I linked in a previous comment. he talks about the dynamics of open source burnout. it's a very common problem and as a GitHubber you are in a unique position to help solve it. |
|
And dead again. |
Hubot is an awesome project. The overall design of the project is easy to understand and hack on. And the async nature of nodejs seems perfect for the task.
But we have one problem: The project seems dead and unmaintained.
There is only one maintainer and he seems to have very little time for this project. PRs with bug fixes or improvements stay open for months. In fact the last code change in Hubot occured on 3rd of April. Since then the only changes applied are documentation updates / link updates / licence updates.
And this zero progress is not due to lack of community interest. Many people try to contribute, submit PRs or ask questions but they get mostly ignored.
So I wonder - Is there anything that can be done to improve the situation?
@technicalpickles perhaps you could consider letting someone from the community help you with maintaining the project? I can suggest @michaelansel as he seems very involved. I also like his work on unit-testing and middleware.
I understand we all work on this at our own will and free time, so I don't blame anyone. I just hope we can find a solution.
Thanks!
The text was updated successfully, but these errors were encountered: