We discussed this morning, how we can get better with handling your issues on Github. We currently have around 100-130 issues open. We manage to close around 20-50 with each release.
There are quite a few issues that hang around for ages and we move them from one milestone to the next. This is not good and we are sorry when it seems like we ignore problems that are known for months. Most of the times those issues are a lot harder to fix than we thought and we already sat down and tried but gave up for now. Other issues hang around because they don’t have a massive negative effect and we skip them because there are more urgent issues. In all those cases we want to communicate better with you to not come across as rude or ignorant. We really want to solve all the issues, but it’s a lot more work than we can afford.
We put issues there that we think are totally valid, but there are more urgent problems that we need to work on first. We don’t want to close such issues, but we also don’t want to put them into a release and then postpone them over and over again. It’s a way for us to prioritise and an honest way to let you know that an issue might take a while to get closed. This milestone is also a good source for possible PRs from the community.
I also disabled a personal email filter that I had created for Github issue notifications to keep my inbox from exploding. I simply often miss issue comments because of this filter and I’m sorry about that.
If you have additional ideas how we can communicate better or get a better overview of urgent issues, please let us know!
i would love to have commit messages relate to issues. currently its hard to keep track what actually changed in code to fix some issues. you just have to mention the issue number somewhere in the commit message or even use the magic like closes #1234 for automated closing of issues.
This is a common issue with any Open Source software or a public bug tracker. Maybe we should have a classification of priority on your ToDO list (example: severe label with a low priority: bug is hitting you hard but very unlikely to meet it in productive usage). Additionally we could provide and ask for reasons why an issue is treated low or high priority because I think sometimes the impact is unclear as an dev:
is a client project delayed because of this?
is this a legal requirement to be able to publish the site?
does it cause much more workload in your user scenario?
is there some deadline involved, like some teaching course based on your new site?
and so on. This makes it more understandable why the issue of person A, where I don’t see an importance at all, is fixed before my very serious all time most important issue .
On the other hand, this increases the workload regarding your organisation in the repos.
Adding issue ids to the commits is very good, yes. Another idea is that we get some milestone which is guaranteed to be fullfilled as it is assigned: If this issue is assigned to milestone must_have_next_release (bad name, I know), I as an user can relay that it’s fixed in the next version and plan with this information, like to communicate it with my client.
We try to do this more often, but I agree that it should be a standard. Unfortunately, our git workflow isn’t fully supported by Github. When you reference an issue in a commit message it only gets auto-closed when the commit lands on master. But we already close issues when we push them on the develop branch. References at least still create links though.
I love the idea of giving more background information about issues. That would be indeed very helpful for us. Many times we can’t tell how urgent an issue is for your personal situation. This could only work though if everyone is adding honest background information and not something like. “Total roadbloack, can’t work without it, needs to be fixed asap” on every issue
The priority labels should give you a good idea how we see the urgency of an issue. If the label is missing, we still need to evaluate the urgency. Give us additional information about the state of your issue (is it blocking your project, making your clients unhappy, etc.) to help us with this.
Difficulty
The difficulty labels should give you an idea how hard it is for us to implement a feature or fix a problem. Some issues seem easier to fix than they are and we might switch the difficulty level after starting working on an issue.
Missing
Watch out for a missing information label or missing discussion label. In those cases we need more background information from you to solve the problem, or we need to discuss the implications as a team. We most likely also talked about this in the comments in such a case.
Type
We try to categorize each issue with those type labels.
Status
This is mostly for us, but it could happen that an issue gets blocked by a bug in a third party library or similar. In this case it will probably have to lie around for a while until we can unblock it.
We hope that this will give you a better idea of how we work with labels and make them a bit more understandable.
Another issue I see with Github is that I can’t create any private issues and there is no ticket system: Sometimes it’s impossible to share additional information about an issue because we would have to give out information about a client project, system data, share project in total or parts, talk about previous experiences with other software compared to Kirby 3, etc. That’s usually nothing you can do in a public Github repo and it’s also mixed comfort for discussions like in a ticket system.
Maybe a Gitlab server with a LDAP connection to this forum credentials would help.
The benefits of not having to care about our Git repo hosting and the huge user base on Github outweigh the missing option to send private issues at the moment. In such cases you can still use our support email address. I know it would be cooler to have all of this in a proper ticket system, but we try to keep everything around Kirby as practical and inexpensive for us as possible. We are still a very small team and don’t have the extra horsepower to care too much about the tools around us.
Oh, yes, please.
.
