redshift
redshift copied to clipboard
jonls
[Question] activity about opened PRs
One more thing, I'd like to ask about active development of the project? As I see a lot of open (and passing CI) PRs, what is your release schedule, how quickly are the PRs here resolved (merged/declined?)
Thank you and keep it up!
Passing CI is great but not the only thing I look for before merging PRs. I would like to review PRs to check that the changes proposed are within the scope of what Redshift should do and also that the changes are technically sound. This is easier for smaller PRs with good documentation and a lot harder if PRs have many disorganized commits and little documentation. As with most open source projects, not every PR is in scope for this project, so some cannot be accepted for this reason. This is mainly because accepting more features increases the work that has to go to maintenance of the project so some features will not be worth it in this sense.
I know there are also a few PRs around that are great and should be merged at some point but really just need some final fixes before they are ready.
Lastly keep in mind that this project is not supported financially in any significant way. So while you may be used to see formal release schedules for larger open source projects, that's not something that I can commit to because most of the time I have other things to do that take priority over Redshift. Similarly, there's no set schedule for when PRs are resolved.
Also (repeating my request from #449) I'd like to know if anybody has suggestions on things can be improved to make contributing easier? I've noticed that lately members of the community are getting more actively involved in trying to help resolve issues reported by other users, which is awesome. That kind of thing really helps me focus on implementing features and reviewing pull requests instead of going through and replying to issue reports.
I'd like to know if anybody has suggestions on things can be improved to make contributing easier?
Like in #449 already mentioned: Add some maintainers to this project.
It's not mainly to have someone to merge and maintain the code. The main point is to have someone who cleans up the issue tracker and the PRs.
So many PRs have merge conflicts with the current codebase. This would at first require kinly requesting the creators to rebase their PRs and resolve the conflicts. Also you may want to close some of them, if these are out of scope.
Also when I read through the bugtracker, there are so much bugs open, which won't take any progress in future.
This would help mainly you, as you could focus more on the code.
I know there are also a few PRs around that are great and should be merged at some point but really just need some final fixes before they are ready.
I don't know if it applies, but please give feedback. Do a review even if you don't consider the code mergeable. A PR and its feedback is a process and not a final thing.
I just recently had it, that I made a PR in a project. It didn't get merged for days. Also other users made approving reviews. I had to ask the maintainer, why it didn't get merged: There was a single edgecase, where the PR would not work.
A bit off topic, but in overall it may also improve the contributor experience. Please release more often. Between master and the last release are ~130 commits and over two years in between. Dangling commits on the master branch are in noone's favor!
Think about it this way: You've made a PR in the last two years. It also had been merged. But you still have to fix up your system manually, because the distro does only ship the latest release. That's a bit sad.
Today I've taken some time to close out old PRs that 1) I think are out of scope, 2) had requests for changes but the author never replied. I hope this will make it easier to see which PRs are in progress.
Like in #449 already mentioned: Add some maintainers to this project.
It's not as easy as that unfortunately. There's no pool of capable and willing maintainers that I can just go and add to this project, as far as I know.
It's not mainly to have someone to merge and maintain the code. The main point is to have someone who cleans up the issue tracker and the PRs.
Nobody has volunteered to do this yet. I could be wrong but I suspect it's because not many people actually want to do this work.
So many PRs have merge conflicts with the current codebase. This would at first require kinly requesting the creators to rebase their PRs and resolve the conflicts.
This is something you can already do now if you have interest in the PR. The authors (or someone else who's interested in getting the PR merged) will have to take up the responsibility at some point.
Also you may want to close some of them, if these are out of scope.
This is something I will try in the future. In the past I've left some PRs open that I think are basically working but maybe not useful enough to be in scope. This was just so user could find them easier (and test them, and provide feedback, and my hope was, maybe improve them to the point where they could be merged). I get that this can probably be confusing so I'll try to close PRs earlier.
I don't know if it applies, but please give feedback. Do a review even if you don't consider the code mergeable. A PR and its feedback is a process and not a final thing.
I try to do this but giving good feedback is really time consuming. It's not so hard on a small PR that changes a few lines but this is not always the case.
I just recently had it, that I made a PR in a project. It didn't get merged for days. Also other users made approving reviews. I had to ask the maintainer, why it didn't get merged: There was a single edgecase, where the PR would not work.
Maybe the maintainer was busy? In some projects it may be okay to expect something to be merged within a few days but it definitely depends on the project. Also, as you said "other users made approving reviews" but if they didn't find the edge case what are those reviews really worth? Someone has to actually sit down and spend a significant amount of time doing a review. It's not enough that a bunch of users reply "cool feature, +1".
A bit off topic, but in overall it may also improve the contributor experience. Please release more often. Between master and the last release are ~130 commits and over two years in between. Dangling commits on the master branch are in noone's favor!
I agree with this. This again comes down to how time consuming the process of making a release is. Some of the obstacles to making more frequent releases have been removed I think. Adding the AppVeyor support should make it easier to release for Windows. Another obstacle that is still present is due to the translations being managed at http://translations.launchpad.net/redshift which is a pain to work with.
In my experience, you can wait forever for volunteers to ask for commit access. What works though (and this worked for me on projects with much less people interested), is to proactively offer it to some people whom in your eyes, made good PRs. I have manged to give off a project of mine completely, with now 4 people having commit access, and .. it just works! :-) I also told all of them, that accepting the commit rights does not come with the duty to have to do something, but that they have the right and my permission to do stuff whenever they feel like it, and mine and the communities gratitude if they do.
In my experience, you can wait forever for volunteers to ask for commit access. What works though (and this worked for me on projects with much less people interested), is to proactively offer it to some people whom in your eyes, made good PRs. I have manged to give off a project of mine completely, with now 4 people having commit access, and .. it just works! :-) I also told all of them, that accepting the commit rights does not come with the duty to have to do something, but that they have the right and my permission to do stuff whenever they feel like it, and mine and the communities gratitude if they do.
This is exactly how I became the maintainer of the Linux flux GUI! I had fixed some bugs around 2016 and after a while the maintainer just gave me commit rights. That turned into me maintaining the project for years, although it has become a sort of zombie project, because the underlying flux program is not really maintained for Linux. Ironically, the current state of that project is that I suggest people just use redshift instead 🙃
Former dunst maintainer here. To keep the project going you have to actively push it away to others. I've learned in this OSS project, that there are enough people interested to keep it going.
If you look at the contributions graph you can see, I was in the second generation of contributors, now we're already at the fourth generation.