Skip to content
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

Closed
mccolljr opened this issue Jun 21, 2019 · 7 comments
Closed

Thoughts on improving the health of this repo. #179

mccolljr opened this issue Jun 21, 2019 · 7 comments
Labels

Comments

@mccolljr
Copy link
Contributor

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?

@tyler-smith
Copy link
Contributor

tyler-smith commented Jun 21, 2019

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.

@taylorchu
Copy link
Contributor

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:

  1. 1 release every 6 months or so
  2. commits merged at least monthly
  3. big improvement happens yearly when we collect some good ideas for a long period

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.

@AdamSLevy
Copy link

AdamSLevy commented Jun 23, 2019

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.

@taylorchu
Copy link
Contributor

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.

@AdamSLevy
Copy link

AdamSLevy commented Jun 23, 2019

@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 go.mod and go.sum file. Each in distinct commits. Each clearly documented in the commit messages and documentation updated where applicable. So I put them all together in a single PR. There isn't much more to write about the PR than what I put in the commit messages. I would be more than happy to expand on it if you have questions or find the messages lacking in some way.

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.

@mccolljr
Copy link
Contributor Author

@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.

@stale
Copy link

stale bot commented Aug 23, 2019

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.

@stale stale bot added the wontfix label Aug 23, 2019
@stale stale bot closed this as completed Aug 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants