Is there still any use of reporting issues to Elgg Github ?

I have been browsing through the issue list on github https://github.com/Elgg/Elgg/issues and there are almost 1.000 open issued. The oldest are from feb 2013.

Wow, that seems a bit silly for an open source project (even much larger projects do not have this amount of open issues). I know the core team is busy and doing this in their free time, but what is the point of issueing things if they are not being picked up in a reasonable amount of time ?

From my end, I am still reporting things (but not all). Only if I am sure that it should be fixed and mostly try to provide the fix in the issue report. I stopped trying to get PR's in since I do not seem to understand your rules for that.

I have multiple issues on elgg core that I have solved on my own sites and I am currently wondering if I shoud spin off my own code base, just to make sure that I am not forgetting to get all those things I fixed.

I know this sounds a bit hard, but do not take it like that. I love Elgg, but also would like things get fixed that are reported by all those users who find errors. My guess is that all the other users feel the same.

  • Gerard,

    please try to do your PR's. The rules for PR's are not all that vague (http://learn.elgg.org/en/1.9/contribute/code.html), but sometimes there is discussion about the naming of commit messages. This can slow down the proces of getting your PR into core, but in the end it will give better readability of the commit history (and changelog/releasenotes).

    I agree on the problem of the 1k issues being open. There is a positive thing, and that is, that it is the same amount as a few years ago, so it is not increasing. Also a lot of the issues are "waiting" for something else (Elgg 2.0, other big change in the system). Nonetheless there are still a lot. The only way to reduce this amount of tickets is to close them.

    The problem is, that closing tickets is not all that easy. That is why we need help. We need people that:

    • check on old tickets and validate if the issue still exist in current versions of Elgg
    • try to write down a conclusion for discussion tickets
    • find out steps to reproduce issue claimed in ticket
    • self assign tickets and solve the issue

    If you reported issues to core, please keep track of your own issues. The best way to get your issue solved is by keeping it "alive". Comment on it, come up with solutions, ask for a fix.

    On a side note; maybe core could declare a special bug fix week in which all Elgg developers focus on fixing bugs in Elgg. In that week core devs should give extra attention to bugfix PR's and try to get them to core asap. It should be doable to resolve 100 tickets in a week with 10 - 20 devs all fixing 5 - 10 issues that week.

     

  • The naming of the PR's was indeed blurry to me, but I do recognize the need for clear commit messages. Still think this could be made easier.

    Regards to checking tickets, verifying and commenting. I'll take some of that work.

    The idea of a developer week is excellent, but giving the number of open tickets it would be better to take a month for this. Microsoft also did that once, where the whole company was dedicated to fixing things and stopped developing. But giving the fact that this is an open source project, it requires some planning to make sure developers can create time in their agenda's and how to handle the load and procedures.

    It would however create a better base for further development. I also want to remark that there is some backlog on coding standards. Almost every core plugin has it's own way of dealing with the same issues, like some have views and pages, others only views. Or some plugins create menus using the class directly, but most use a hook.

    That makes it harder to create plugins that modify behaviour and also makes it more likely that people modify core and therefore create their own legacy.

  • Realize you're asking us to fix bugs faster AND rewrite all the bundled plugins to be designed consistently AND do more work to write release notes because you don't want to have to learn the commit msg guidelines.

    I do appreciate the difficulty in getting PRs into acceptable shape. I think we could whip up a tool that would take a PR, give a form to make writing the commit msg easy, and the tool would squash all the PR commits, rewrite the msg, make a new PR, and close the old one. This would make it easy enough for core devs to just do as part of reviewing if they wanted to.

  • @Steve, no that is not what I am asking. The commit msg guideline is only a side step in this discussion.

    I think that rewriting the bundled plugins could simplify Elgg and reduce the number of API calls and therefore reduces the number of issues. But this is not the main topic either, this was again a side step.

    The discussion at hand is that I think fixing issues should have priority to reduce the total number and not having issues that are almost two years old.

    In the interest of the project itself, my personal remarks are to clarify some of the benefits like not having to keep track of solved issues and therefore more easy upgrades. I was only pointing that out, to let you guys understand what happens if issues are not solved. A lot of people are probably just waiting for it to solve.

  • Or worse, lose interest !

  • I think there's some confusion to how we handle tickets. The number of tickets is only tangentially related to how new tickets are handled. The tickets aren't resolved in order, and they also serve other purposes than reporting bugs and making feature requests (historical records, todo items, research reminders).

    Basically, if you submit a ticket that needs to be addressed, it will be addressed within a few hours. If you don't report new issues that you find, how we will fix them? If you're waiting for an open ticket to be resolved and have fixed it already locally, submit a PR. If we've dropped the ball on that PR, ping us. If we've closed the PR, it means that isn't an approach we want to use, so ask for feedback.

  • @Brett, I am probably not making many friends with core team today, but I am still not convinced. What you are saying is probably true for a large number of tickets.

    But for instance, Evan just closed an issue that was raised 25th of november 2013 and was considered a bug by Matt Becket. It came back alive because I commented on it and to be honest not solved in any of my suggested ways, but just closed. 

    Regards to response within hours, that is also not what I experienced. I currently have 7 open tickets, where the oldest that can be considered as a bug is 25 febr and that particular one has no response received.

    I want to stress again that this is not about me or my issues, but that is just the best reference I have here.

  • Okay, what practical and implementable suggestions do you have that would address the problems you're talking about?

  • Also, these are very important parts of my last reply might have been overlooked:

    If you don't report new issues that you find, how we will fix them? If you're waiting for an open ticket to be resolved and have fixed it already locally, submit a PR. If we've dropped the ball on that PR, ping us. If we've closed the PR, it means that isn't an approach we want to use, so ask for feedback.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.