I’m just an user, with no special skills for code, but
Considering that there are too many issues labeled as “Bug” (446 open) in Github
Considering that 56 bugs are from 2015 (2 years)
My proposal is
A- USERS work - to ask all users to revisit all open bugs and confirm if they are still an issue.
Some of them probably are already solved but all need to gain attention again so later they could be moved to the solving process.
This way we could also reduce some backlog on ISSUES.
Lets say each bug needs to be confirmed by 2 users (original authors are also welcome to re-confirm)
How to do that?
1- Pick a bug (oldest first): https://github.com/salesagility/SuiteCRM/issues?q=is%3Aopen+is%3Aissue+label%3Abug
2- Try to replicate it with version 7.8.2 (use the official demo version or a SuiteCRM clean install with default values)
3- Take a print screen of the issue
4- Make a reply on the issue with this words: Confirmed in 7.8.2
(include the print screen, if available; Github works fine with attached images, no need to external sites for pics)
=> B) So please: No code confirmation, no fix test (if any is provided), just plain and simple issue confirmation for the 7.8.2 version
Note until version 7.8.3 released: for this to work faster, to have more time to work on bugs, please place on hold any improvement on the templates area.
I also value when SalesAgility responds quickly to the new Pull Requests made very recently. This has been handled quite well in recent times, some simple things got merged almost immediately.
It might seem like a not-so-good way to prioritize (only because a PR is new, it doesn’t have to be more important than the old stuff), but I think it makes some sense: it keeps contributors engaged, and things get handled while people still have them in context, and are motivated and available to work on them. It also lowers the risk that the PR will become outdated, and have conflicts or become redundant.
So if you only work on 2 or 3 PR’s a day, it makes some sense to look at the ones just created. Especially if they are no-brainers and fixes for typos.
Of course, getting rid of the backlog needs more than that, so Horus68’s proposal looks good. My comment is just a side-note (don’t let things add to the pile if you can avoid it, with advantages).
This guy is a SalesAgility employee, works very actively for months doing 103 (!) Pull request with tons of fixes, most of them quite simple to merge, and his work isn’t pulled… why?
And then another thing that intrigues me is when they all disappear for a week or two, like is currently happening. Github is usually frantic with activity, but now it’s completely stopped. Sigh…
There are usually some replies on time not available to test or to merge things.
I’m sure this is a real thing. But what if Salesagility as time, would it be different? I’m not sure! I think is a workflow issue (there’s a module for that!)
For me there is a thing here related with the way this software is managed.
In the world of OpenSource there are many models, specially the “community managed” software and the “company managed” software.
“community managed” software works like this on merges: users create an issue, a PR is created, its tested successfully by a minimum of X number of members and then merged. Those projects includes also an area (sections forums or chat systems like slack) for specific teams where people can campaign to request other users to test a PR so they get merged fast.
Then things move on to the next issue that gets a PR. Projects also includes issues/PR created by a production team so new features are included, not just bug solving. This is all public in a clear release schedule plan.
This goes on in big teams projects (see Joomla CMS https://github.com/joomla/joomla-cms) or with small team projects (see Bolt CMS https://github.com/bolt/bolt)
On the other hand “company managed” software must balance 2 things: plain users that help solving issues and the company needs (the needs of their own clients). Bills must be paid and life gets in the middle of software development and bug issues!
So a PR can be merged in the spot (if the company needs it for their clients) while others are ignored or take longer to be merged (the ones not needed by their clients).
When time allows there are also some bug fixes and PR merged (mostly before each new release) and some new features implemented (not in a tiddly schedule plan).
SuiteCRM its a software that I thinks mostly fits this category. Sometimes I see some messages around that Salesagility do not want to be on this category, but that is not easy to be in the other category and there are not much middle groud to be in!
I see some numbers: 184 issues with a “fix proposed” label https://github.com/salesagility/SuiteCRM/issues?q=is%3Aopen+is%3Aissue+label%3A"Fix+Proposed"
What will happen to them in a year?
Please do not ask us to test them all at once if you are not planning to merge them before next 2 versions if successfully tested.
Been there, done that, many community test do not gets merged also!
To request community help please focus, narrow the requests and go for it!
So this all goes to a Workflow system. What workflow Salesagility have now and what it wants to implement.
I don’t know if you all noticed, but this Saturday samus-aran was busy for about 10 hours merging PR’s. That was a long day, on a week-end, and she got 15 PR’s merged, if I’m not mistaken.
The previous two weeks were VERY slow on Github. Everybody from SalesAgility mostly disappeared. I always assume the best: they are busy doing good things for the project, away from view. They are focusing and getting things done.
This week, things seem to be slow again (though not stopped).
If I was Greg Soper, I would just plan so that samus-aran, and maybe others, would spend an entire week or two, full-time, merging 15 PR’s a day. Just reaping all that value that is waiting to be released into the product. There are so many bugs already fixed, so many small features that could be benefiting everyone.
And we have already mentioned how delays tend to compound problems (repeated forum work on bugs that are already fixed, conflicts when merging, etc).
But since I am not Greg Soper, I admittedly don’t see the whole picture, and don’t know what’s holding them back from merging PR’s (except with a burst of employee generosity on a Saturday), and I have to admit there might be good reasons. Evenm if they’re all just working on other projects that pay their salaries, that’s fair enough.
So a big thank you is in order for samus-aran, and let’s hope things go well for SalesAgility and they get a chance to invest some more time on merging all those “Fix proposed” solutions to Issues.
Yes, March has been an EXTREMELY busy month, but everyone is right, that is no excuse for the lack of activity.
So everyone we very much appreciate your patience and we will be addressing the community today with our Community plans in regards to Suggestions, and Community Testing and hopefully tackle this goliath of a task once and for all.
Hopefully the announcement will provide you with some clarify.
I just read the Announcement. I’d like to add a few thoughts to that thread (actually your text invites us to share our thoughts), but it’s an announcement, so we’re not allowed to reply there. Can you please open that for replies, or should we create a new thread to discuss the Suggestion Box?