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.

  • One suggestion came from Jeroen, organize a developers week were at least core team and/or core contributors are dedicated to fix issues.

    Another suggestion could be to prioritize more on issues than on new development until there is sufficient amount of issues solved. Solved should include user satisfaction from the issuer to ensure that he will keep participating which is crucial for open source.

    Third was make the PR submission easier or add comments to the PR to make sure that you can track and trace back when necessary. Setting the bar high on your own standards on how to submit a PR will not get you much PR's and that is probably exactly what you do want to acheive Isn't it ?. So circumvent procedural issues whenever you can.

    As to your last remark, sure an issuer can take more involvement and he will if he has a real need for it. But developers who could help your team,  do not have such a need, since they can bypass or solve the issue anyway. They will see a lack of interest if issues are not picked up and go more and more to the sideline.

     

  • A lot of these things were addressed in the link Jeroen provided earlier: https://community.elgg.org/discussion/view/1887312/consolidating-duplication

    Another suggestion could be to prioritize more on issues than on new development until there is sufficient amount of issues solved. Solved should include user satisfaction from the issuer to ensure that he will keep participating which is crucial for open source

    These are pretty broad strokes. What's "sufficient?" Do we need to hit a backlog of 0 before moving on to the next feature release? What is "user satisfaction?" We close tons of issues as Won't Fix because a feature can be implemented in a plugin.

    Third was make the PR submission easier or add comments to the PR to make sure that you can track and trace back when necessary

    I don't buy the PR complaint. If you want to be involved in an OSS project as a contributor, you have to learn how to contribute. We've adopted a policy of walking a new submitter through the process and accepting a PR if it means we have to manually rewrite the commit message, but being part of an OSS community means learning how to operate within that community. We want high quality PRs, so we have higher expectations on how they should look. I honestly don't think this has negatively affected the number of PRs but it certainly has positively affected the quality of them.

    As to your last remark, sure an issuer can take more involvement and he will if he has a real need for it. But developers who could help your team,  do not have such a need, since they can bypass or solve the issue anyway. They will see a lack of interest if issues are not picked up and go more and more to the sideline.

    I don't fully buy this either. Sure, we've dropped the ball on issues, but we can't be blamed for when the submitter does the same. OSS is a team effort.

    Something interesting to consider -- Many ticket systems automatically close tickets with no activity after X many days after sending out warning emails. If we were to implement this, what would the effect be?

     

  • To sum it up ! You don't think this is a problem and none of the suggestions I gave (on your own request)  are considered to be usefull feedback.

    That closes this discussion. Thank you for clarifying your view on this.

  • I think this is a valuable discussion to have. Jeroen's initial suggestions about how to help with bug triage were spot on. If you want to help, please sign up at http://codetriage.com/elgg/elgg and help us get the bug count down. This is the equivalent of the bug bash week except optimized for busy people over the long haul. Anything you can do to move a bug closer to resolution is appreciated. Gerard, I think you have valuable points in everything you brought up. We just can't implement the ideas exactly as requested for the various reasons I won't rehash here. There needs to be some give and take. And at some point we do need to say "no." Elgg core can't be/do everything... For the PR standards in particular, I hope you can appreciate that we've been releasing every two weeks for months now almost without fail. This has never happened in Elgg's history. That is a direct result of our PR standards. We are open to ideas about how to make that easier.

  • @Evan, thanks for the response. I will take a closer look at Triage these coming days.

  • To sum it up ! You don't think this is a problem and none of the suggestions I gave (on your own request)  are considered to be usefull feedback.

    No, that's not what I said. I said some of the things you've suggested are already happening, asked for clarification of some of the ambiguous points of your first suggestion, and reminded you that OSS projects are a joint effort that might require learning a new set of tools or a new way of using those tools.

  • @Brett, I had a pretty long talk with Yuho, partly on this subject and he told me some of the benefits you have acheived. The triage thing Evan commented about, is also a good initiative.

    I still feel that (non core) dev involvement is too low in general and issues are too high, also that it is the projects main responsibility to facilitate that, but I decided not to interfere or suggest anymore on this topic. And I also learned the last days that you are doing a lot on this part.

    I will probably start new discussions on a different User Experience and joined plugin development which is quite rare in Elgg. Juho told me that there were some very good thoughts on that last subject, so I will wait for  that first.

  • "Working on existing issues" vs. "Opening new issues":

    There is a huge backlog for sure and I would also see it reduced if possible. On Elgg 1.8 and earlier there were always about 20 issues selected to be fixed for the next release (in addition to any severe issues poping up that needed to be taken care of with priority). For Elgg 1.9 this approach is not continued anymore:

    • to allow for a date based release schedule as opposed to a feature driven release schedule,
    • because all developers are volunteers and should be fully free to work on what they want.

    Both reasons are valid for sure. Still, it seems to me that this change in the approach resulted in a concentration of work on new things and maybe neglecting existing issues quite noticeable. I can understand it to some extend. It might be more interesting to work on new fancy things (that surely can Elgg bring forward immensely on the long run) and might seem "more important" to have some bigger changes ready for the next feature release of Elgg (1.10...). At the same time there's this huge amount of long-time open issues that maybe refer to little annoyances only in some cases. But does it make sense to put aside dealing with these issues again and again just to get "new" stuff in the next upcoming release of Elgg?

    Most likely some of these issues are open even much longer than Februar last year because this date refers to the move of the issues from Trac to Github. It might be worth taking a look at the issues "owned" by elgg-gitbot as these are the old issues from Trac. The question is: are at least some of these long open issues outdated (maybe even fixed) in the meantime? If someone (or even more than one) who has a good knowledge of Elgg core would check this out, it might be a good chance to close quite a number of issues. I've sometimes looked at some of these old issues but I have to admit I feel at a loss to decide if they are still revelant or not because I'm not that into Elgg core.

    It might also be worth trying to group similar issues or create some kind of "meta-issue". Fixing such a meta-issue might not even be more complicated or time-consumung than working on the original issues as it might be more efficient to work on a specific area in code to fix several issues instead of different developers (or the same developer at different times) working on it independently.

    "Bug-fixing week"

    It might sound appealing to "fix ~100 issues a week" but is it realistic to get more than 2 or maybe 3 people together for a whole week to solely work on it? "Volunteers work", i.e. working when you are in the mood and you can afford spending the time. If the work would be done by less people at the same time on their own weekly schedule but regularly there might be less than 100 issues fixed per week but maybe the total number of fixed issues would be the same within a longer period (e.g. 2 or 3 months).

    Providing PRs to Elgg core

    I have to admit that I also don't fully understand the explanations in the docs how to provide a PR with a correct commit message. It seems to me that instructions are just a fraction too briefly written. Regression tests? Unit tests? What exactly is required by me to do? The problem is that people might feel discouraged to even start working on a PR if they have no idea what exactly is expected.

    On the other hand I don't follow Gerard: I don't think that it's very likely that people don't provide fixes they already made for themselves because they feel at a loss at github. If the coding is already done the step to make a PR is a much smaller step. And not trying to get the fix into Elgg core would mean that you have to merge your changes again and again after each new release of Elgg. This seems even more annoying to me than trying to understand how the commit/PR process works.

  • Regarding to the bugfixing week; it is not the intention to bring people together offline, but more a special focus week were contributors all over the world can participate in by providing PR's. And core developers will make some more effort to get PR's in.

    I don't think there is too much of a focus on new issues instead of older issues. Like i said before, the best way to get rid of the tickets is too close them. The only way to properly close them is too give them attention. Fix one before moving onto the next. As a reporter you should provide good issue descriptions and give quick responses to followup questions.

    Most tickets have a open ending, there is no conclusion, or it is waiting for someone to make a PR. Doing triage on the issues will help you in this process. Or just browse the tickets and pick the ones you need, like or think you can fix.

    In my own experience is that the core developers pay really good attention to new and updated tickets and are quick to respond.

  • From my experience, whenever I posted something in GitHub, I get responses in short time. Keep in mind that this is a OSS, the response time is good here.

    There's a OSS that I integrated in elgg, and it has a huge bug that someone reported before me and hasn't been answered in two and a half years.

Feedback and Planning

Feedback and Planning

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