-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts on improving the health of this repo. #179
Comments
dbr was originally created by @cypriss and myself (mainly him) while we were working at UserVoice. I left the company and project in 2016, no longer have contact with any of them, and due to the nature of the departure requested my information to be removed from the copyright and readme. As far as I can tell crypriss has also given up on the gocraft project as he has a sweet gig at another company these days. I suspect all the gocraft repos are essentially deprecated at this point and changes are only related to what is needed by UV to support legacy software. Personally I just use a fork from around when I left the project and it's been good enough. Only a few small patches made. If dbr is ever going to be anything but decaying abandonware it needs to be opened to the community for management and needs some smart people to take the reins. People who care about the project. As it is it's just becoming viable for fewer and fewer people because of plain lack of care about it by the new maintainers. |
yeah, good points for improving stale bot. But I still think that it should be closed maybe after 180 days or so (not 7 days) due to low activities. dbr is doing ok:
It is true that I don't have time to groom this daily, so I welcome people to submit "small" PRs, and contribute to the discussion. Anyone could be a maintainer if he or she contributes frequently. |
I really like the approach this repo takes to query building. However, I too have decided to move away from it because of the lack of active development, but mainly because of the "stale bot" and the attitude about closing issues blindly and automatically that @taylorchu just expressed. Even if the time for automatically closing issues is extended, this reflects a fundamental difference in beliefs about the role and importance of issues and open source development and maintenance from the one that I hold. I believe that no issue should be automatically closed due to inactivity. That is how serious bugs are ignored. I disagree that dbr is doing okay enough for me to want to keep using it when Issue #167 is a critical issue that I reported that would have been closed had I not made another comment. It still has not received any substantive attention. As it stands this library does not generate correct SQL syntax for a pretty common query that the library claims to support. My PR solving this and other issues has also gone ignored. So when you say that "anyone could be a maintainer if he or she contributes frequently" I struggle to see how this could ever occur with the current level of communication and response on open issues and PRs is next to nothing. I can't contribute frequently when no one is responding to my proposed contributions. This is particularly discouraging when at @taylorchu's request, I took the time to resubmit a second PR (after my first one was closed by the stale bot), and still got no response after this. I would reconsider my position and would again want to use this package if these open issues were resolved, and I saw more engagement from the current maintainers with open issues and PRs. Even just once every 2-3 weeks is enough to keep most open source developers engaged with any issues or PRs they submit. I appreciate this discussion and hope that this code base can be brought back to life. I see that a new release has been made, and appreciate seeing activity on the repo, but it still suffers from critical bugs, so I can't use it at this time. |
A PR that fixes 3 bugs and has hundreds of lines of changes takes time to review and test. In general, it is unclear the intent of some code change, and that will cause its delay to get merged. I would really appreciate @AdamSLevy to break down the changes to be bite-size. You can see smaller PRs (with tests) here get merged quickly. |
@taylorchu I would be more than happy to engage with you on specific issues about my PR on the PR thread itself. I would like to state here though that I believe you are mis-characterizing my PR as excessively large, but that seems to me to reveal that you likely haven't reviewed any of the 3 well organized commits with very clear and complete commit messages describing the intent of the change. Although the diff is that large, I do not believe hundreds of lines substantively changed. Finally, I have added or updated the tests for the fixes I implemented within each commit. My first PR that I submitted did only fix one issue. It fixed Issue #167 in which completely invalid syntax is generated for UNIONs of SELECTs. I received no engagement on that PR from you to the point that the PR was automatically closed. You asked me to reopen another PR on that issue, and since then I had opened and resolved two new issues, one a syntax generation error for OFFSET, and the other simply adding a I don't know what more communication you want from me about my code changes beyond this. Perhaps I have been unclear somewhere, or you don't like something about my changes. That'd all be fine but how would I know? Did you just ignore the PR simply because it fixed more than one issue? So here I am, contributing to your repo in the way that I would appreciate and accept someone contributing to my own repo, and rather than working with me you are making me jump through hoops that are being communicated after the fact. This doesn't encourage me to keep contributing. The result is that these bugs still persist, and my personal interest in making the repo work for my purposes is waning. |
@taylorchu I respect that this is an open-source project and you aren't getting paid to maintain it. I cannot ask you to contribute more time than you have available, but I also do not feel you are able to give enough time to this repo for me to consider it "actively maintained". It feels more like "end-of-life support", and that seems more true than ever based on @tyler-smith's statements above. I cannot, in the current state, continue using this repository. If there is not another maintainer that can be granted rights to review and merge PRs, then you are, unfortunately, the bottleneck. I opened this issue to express my concerns and reasoning, and it seems that you are unable to fix them at this time. Like @AdamSLevy, I believe you and I have a fundamental disagreement on how issues should be handled in an OSS repository. They should never be auto-closed. Look around github. How many other repositories have years-old issues used for community discussion and solution tracking? It is clear that you are approaching maintaining your repository differently than others. Whether that is a good thing or a bad thing is up to you, but it remains a clear fact. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I have, at least at this time, dropped DBR from as many application as I can. This library was great for a long time, but there have been a few incidents (suddenly adding a massive OpenTracing dependency, aggressive issue closing, an apparent lack of support) that have made me turn to other solutions.
I think a good step to revitalizing this library would be to give more rights to the community and contributors, as it seems like you yourself are distracted with other things (such is life, it is totally understandable). Removing the Stale Bot and allowing issues to stay open is a good thing. Having issues on your repo is not a negative reflection on you. It means people are using your software in new and interesting ways. Leaving issues open is also useful for a number of reasons. They can serve as a place for contributors to discuss how to implement certain features. They can let users of the project note when they're experiencing the same issue as someone else and discuss workarounds/problems etc. I've never seen another project aside from the Go language itself (which has thousands and thousands of issues) aggressively close issues like this repo does. @AdamSLevy has also noted that this is a non-standard approach running a repo in another issue.
Perhaps a change to only add a
stale
label, rather than closing the issues? I understand that this is not a paid gig for you, and I can appreciate the time commitment of OSS, but in order for dbr to be viable for me again, I would need to see a more engaged maintainer. Is there someone you can share maintainer rights with who has more time to commit to this project?The text was updated successfully, but these errors were encountered: