Suitecrm: New Milestone 7.10.11

[Mausino]

I copy only my answer here on @pgorod from ticket #6429 why is milestones for us as community important. If you thing that belong to Forum.. will close this ticket and apologise if was for you spam. The lates milestone isn't closed and there as stucked issues. Will @salesagility continue in milestone tradion?

[pgorod]

Hi Mausino!

as a bit of a background - when we first started using milestones it came from a different perspective, more looking at the past than to the future: we were trying to find a way to label solved issues and merged PR's in a way that we could determine easily "this was fixed in version 7.8.18", for example. So it was intended as a labeling of merged PR's by release.

But the Github feature is meant to be used to manage future releases, and we naturally started doing that, labeling the things that we wanted to include in the next version, and sometimes the one after the next. But we didn't look at this as "commitments with the Community", so we don't really think twice when re-labeling something for a later release. It is just a practical decision of what we can put into one release, and what we won't have time to include.

But I am glad you noticed the milestones, and I am glad you started this discussion. If the milestones are a way to focus the Community and get more help fixing and testing, that would be great. Maybe we can start thinking of this differently from now on.

A different problem is the bottleneck testing and merging PR's. We have limited resources to do this work, and in recent times we made it more complicated with the introduction of automated tests. This is making us slower now, so we can be much, much faster and more reliable in the future. But I agree with you, as long as there are many Fix proposed PR's waiting, the incentive for Community members to make new ones is lower.

Anyway, some of those proposed fixes are low-quality, or high risk, or both, and in many cases we have looked at them, and decided to let them wait. Maybe we could label this more explicitly.

About my request on that post - if anybody has quality developer time they can contribute, they can also approach us with that offer: I have X days of work I can offer, I would like to focus on Issues with module Y, what should I do? We can try to organize that work.

Or if they have money to invest in SuiteCRM, they can purchase consultancy services from SalesAgility to fix the Issues more important to them - this buys developer time from our Teams working on Projects, to contribute to the Product. Companies are saving so much money on licenses when they choose SuiteCRM, they could surely invest a fraction of it to push the project forward. In the end everybody benefits from other people's investments.

This is just my personal opinion and view, if @samus-aran wants to correct something in my explanation, or offer any further thoughts, that would be great. Thanks

[samus-aran]

Morning @Mausino!
Just to follow up from @pgorod points and no this isn't spam its valid question in an appropriate place. As you've seen we have been getting to grips with the milestone planning and as pedro described we were using them with the intention of setting our internal sprints to. However in order to do that we needed to (and still do) gauge and accurately estimate what we can or can not achieve within a milestone i.e. what x% of tickets can we realistically achieve within it. We didn't intent to make this commit in the early stages but I don't see why we can't provide that transparency of what we are working on later once we have a more accurate velocity. I'm happy that we completed 60% of the 7.10.10 milestone but that was a huge overestimation and that is what we want to avoid for future milestones so it will take a few more milestones to get that balance right. Of course that is our aim, but we would be more than ecstatic if the community were able to assist and take up any items that in a milestone to help us to achieve that milestone target.

Following up from the 7.10.10 you are absolutely right that there wasn't a 7.10.11 milestone to move the remaining into and really that was just down to us being pre-occupied with the 7.11 milestone. So we'll create one and move some those spill overs from 7.10.10 into it.

[Mausino]

@pgorod

we made it more complicated with the introduction of automated tests

• this is great forward... without automated tests this project have not chance to success as you wrote it's save us lot of time in future

@pgorod @samus-aran

Anyway, some of those proposed fixes are low-quality, or high risk, or both, and in many cases we have looked at them, and decided to let them wait. Maybe we could label this more explicitly.

should you add new label like "low quality code " or "high risk code" you'll label slowly the FIX PROPOSED issues in which you'll in touch and we as community will know that good fixed issues will added added to milestones + get label (need tests) or if fix proposed issue will need more work on it.. will get label low quality code or high risk code and close them.

For us is better know what copy and paste to our instancies from github becuase if i see Fix Proposed that the code is good.. but in many cases isn't. Better close fix proposed "solutions" as will only flying over time.

When community get direct input what is good fix and what wrong we can move forward.. but if will the number of issues rising bercause of 200 issues is proposed and every new (potencional) user/custome will looks on github will thing... so many issues... this is waste product... and this we wont. It's better have 300 relevant issues as 800 issues (and from it half irrelevant issues)

@pgorod @samus-aran One more question..
why the suggestion are moved to trello (out of github) if can be managed as new project in github ?? (like API) where is kanban (same as in trello) and will people dont lost in management of new featuers. If will suggestion in project will easy also assigned to milestone and we will know which new future is planned (is working on) and we can help/test/comment or whatever. (Now i have feeling that suggestion are lost in trello for us as commuinty.. )

Sorry for english.. not enought time to check my thoughts. :)

[pgorod]

We'll have to think more about that labeling of older Fix Proposed PR's, because I believe low quality code is a bit aggressive for the person providing the fix... but I'm sure we could come up with a more generic, and kinder label, like On hold, or Needs improvements.

Or maybe a good idea would be to label the other ones instead: Good quality, Easy merge, or whatever.

About Trello, I guess we all realize that move didn't work out as well as we hoped. It's hard to get an additional community operational, apart from GitHub and the Forums. You are probably right that something better could be attempted here on Github. But note that this move was motivated exactly by the kind of thought you propose above: trying to bring down the number of Issues on GitHub, so that they are significant and we can work on them with order!

Somewhere in the beginning of next year I hope we can move our Forums to a better software and then we can also explore ways of managing suggestions there, I think it looks promising.

[gunnicom]

We have limited resources to do this work
That is true, but your priorities are wrong.
Fixing all these bugs is more important than "The focus of SuiteCRM 7.11 is to introduce Elasticsearch and Google Calendar Sync"

Honestly who needs Google Calendar Sync, if the sofware is unusable in some places (Reporting is broken beyond repair)

and in many cases we have looked at them, and decided to let them wait.

Some reported issues date back from 2014. Almost 5 years. Of course some issues will just disappear over the years.

I have X days of work I can offer, I would like to focus on Issues with module Y, what should I do? We can try to organize that work.

I would put more work into Suite, but with the knowledge, that proposed fixes sit there for years and nothing happens, i wont do that.

But note that this move was motivated exactly by the kind of thought you propose above: trying to bring down the number of Issues on GitHub, so that they are significant and we can work on them with order!

And what happened? Nothing changed and now the issue count is as high as before.

[pgorod]

@gunnicom

I still think it was a good thing to try and separate onto Trello the things that aren't necessarily actionable. Ideas are great, often we like them, but they can also be quite unrealistic or dreamy. That's ok for ideas, but it's better to leave Github for the more actionable things - things that, if we had time, we could move them forward with some practical work, and without too much "philosophy".

I agree with you there should be more priority fixing bugs. That is also my view, since my role is basically tied to troubleshooting and yes, it gets repetitive. But I think it's also understandable that other people in the team need to be concerned with other things that also come into the equation: marketing, projects, human resources management, etc.

Anyway these two perspectives aren't competing with one another, they are complementary. It's easier to market a product with less bugs and better reviews; it's quicker and more lucrative to make projects for a product that is more reliable. We're all on the same boat.

---

Now, back to our essential bottleneck: how can SalesAgility do a better job of moving PR's forward and merging? In the past year or so, we've been getting more conscious of all the issues with regressions, and we've been improving processes: tests, assessments, etc. What is happening is that it is more reliable now, but it is also more laborious.

The Community can also do (at least a good part of) this job, although it takes an additional effort (and not everybody will be able to do it). People can start providing PR's that have tests added to them, people can work on manually testing, and report on that work, and some people we would even trust for code assessments, once their work proves they have the necessary skills.

One idea I've been considering for a long time is specialization by scope. I'd like to hear what you think of this...

So imagine you feel a professional interest in improving the Reports module. You slowly start studying that module in depth, re-factoring, and writing some tests around your development, reading code to improve quality, perhaps writing better docs (if that's your thing). As you propose more PR's around the same module, it's becomes apparent that you know what you're doing, that you are aware of all the implications of each change, and it starts feeling safe to trust your code and move it forward through the merge process more swiftly.

With a dozen people doing this for a dozen modules, we could improve quality quite fast, imho. And I believe it could be easier to manage by SalesAgility, because it would all be more consistent and complete, instead of the current situation where we have 100 PR's each about it's own small thing, and no tests...

Let me hear your thoughts on this (and also other people!). Thanks

[gunnicom]

For me, i can say, that i will not put more time in Suite for writing tests, as long as i think, that nothing would change. I would put more work into it, but issues and pull requests will still lie around for years. Thats opinion based, but that is how i see Suite on github.

[pgorod]

Well, let's hope we can improve and, with time, regain your trust. Thanks for your honest input.

[Mausino]

We as company tried used by our developer to help some users with fix + add "solutions" on beginning of this journey. But when many months or years are our/community Proposed Fixes lied there.. we stopped this activity and now we're primary report the issues / test some proposed fixes or help some users of community with tickets.

We're not expert on everything. We have developers on part time job.. their work is fix the issues or create small enhancement of SuiteCRM. Our budged is small. Yes, SuiteCRM is free but cost on customization and upgrading are rising every year. Why? Because we using the patches from github to fix pain issues which are not merged yet and every upgrade of SuiteCRM become nightmare, because differences between or instance and official is still bigger and bigger. Still is here something new and need to check if override our enhancements or patches from github or change whole behavior of some module (like in 7.9 the disaster with emails which still persisting also in 7.10 and will in 7.11 👎 )

In the past year or so, we've been getting more conscious of all the issues with regressions, and we've been improving processes: tests, assessments, etc. What is happening is that it is more reliable now, but it is also more laborious.

Here started our headache and next reason why we stopped by developer any code activity here. When your pull request want be success you must do the test.. the test are timeconsuming to understand/learn it and for junior developers totally disaster(their are happy that learning/(know some parts) structure of SuiteCRM). I think we (95% members) are working and contributing here by free time (every must go to work and pay fist own bills) and after look here and try to improve the idea of free good CRM.

Our developers wont(need invest time to get into it) do the tests.. it's hard for them. They haven't problem provide our solution/fix but we haven't enought money to pay for doing on additional tests. We're happy that we fixed issues, because there is waiting list of many others issues which wasn't solved here.

Conclusion:

• Need to separate the Fix Proposed tikets/pull requests to Good quality or Bad quality fixes.
• Bad pull request should be closed. No mercy :)
• Good pull request cant be hold that haven't the test/assessments.
• Good pull request should be merged and create for each the task in new Project (as we have for API) (with name TESTS) for adding the additional tests/assessments to pull requests.
• We need special person or community members which will do only tests + assessments for new or old pull request (we spend 10 hours on written one, special person do for 15 min).

When we will have SuiteCRM github projects like APIs, Suggestions, Tests and we will keep milestones the SuiteCRM (big thanks for @salesagility ) will move forward. That's my opinion. Don't know if see others it by same eyes as me.

[pgorod]

Thanks Mausino there are quite a few points in your message that we will need to review and discuss internally. This sort of thing is indeed helpful to us.

I am particularly thoughtful about your concern with writing tests. I agree with you that the learning curve is not negligible. Sometimes you just want to contribute a fix with a few lines of code, you don't want to be forced to write tests for that module, particularly if that module currently has no tests at all... that is understandable.

We are still figuring out what is the best approach here, but we currently don't _always_ demand tests for every PR. We make a case by case decision, whether it is risky and _needs_ tests, whether it simple... So recently you've seen cases of...

1. We merge without any tests because it looks trivial
2. We ask for tests but then merge anyway if they don't come
3. We ask for tests and walk the contributor through the learning process
4. We write the tests ourselves and then merge

On the other hand, writing tests after the initial learning curve can become very fast. It is also not the most demanding task in terms of developer skills. Some acceptance tests (sequences of browser clicks) can even be done by business workers, as long as they have _some_ technical ability.

For this reason I would still prefer to have more tests getting written by people outside SA, so that we can leave our experts with more time for the really hard stuff.

So I believe even a small/medium company could perhaps devote some developer time (say - Friday afternoons for a couple of months) to write tests, focusing on a single module, trying to get it to a state of full coverage. So - not writing tests for a single PR, a single fix, but for a module's basic functionality.

If we could get this to happen with a decent number of helpers, you would be spending money on it, but getting a lot of return, since essentially everybody would be working for everybody else. But I know this will be hard to get moving...

If we don't break this down by modules and functions, it's always going to look like an endless job and will never get done...

[horus68]

Reading you all, I agree with many of the questions aimed to the way SA organize the users collaboration here in GIT.
Lets be simple and direct: You can't expect users to be involved when a patch is not approved or rejected in a month time. Even when other users say it works, sometimes not even get a simple reply from SA devs.
This is a strange thing on an opensource project: Here is not the users who do not test code fix, is the project head! Its strange.
Alert: You are just loosing people doing what you are doing now.

A- Start by taking control of the PR backlog (243 waiting), test things, merge more, reply more, close more PR. Use 2 rules (even if I don't like those, you are not able to do better then this):
A1- A project can't have PR open for more then 2 version releases of the software. After that it just cause problems to users.
Merge it or if you don't want it the just say so. Simple make a reply to it with a polite:
"This will not be merged as we don't think it is useful to the project, because even it can solve some issues it will cause other issues / or it does not follow the direction that we want the project to take in the future."
As in: we don't like this, move on. Close the PR, tag them with "Not accepted". Whoever wants to use that PR will have the power to do so, but on their own.

A2- Any PR created by SA team (except the dev brach) needs to be merged before releasing the next version. Else it should be closed.

B- Then move on to the issues (839 waiting) and create a plan of work:
B1- Each moth you need to close 10 issues that do not require PR
B2- Each moth you need to create 10 PR to solve issues

[pgorod]

About issue closing...

Our best month (January this year) we closed over 300 issues. On average we close well above 100 per month. I have to admit that the past 6 months were not as good, regarding these stats, as the 6 months before. This has to do with team issues and with pressure from other duties we have.

By the way, do you know what happened when we did more Github work? The Community opened a lot more issues, reacted a lot! It was great, but it didn't bring down the number of Issues or PR's waiting...

It's easy to underestimate the size of the project, the size of the Community, and the effort that this Github work demands. We underestimated it too. Really, guys, we're doing the best we can, and it's not enough, and it will never be enough.

So it seems we're stuck:

• we need a significant increase in help from the Community
• the Community complains they can't help anymore because of us being a bottleneck

Now, I don't think that I am right and you are wrong. For me, both of the points above are true. So, I think you are right too :-) I would act the same as you if I was in your place.

But so, how can we become "unstuck"? Believe me, the answer is not just "SA needs to do more". If we can, we surely will. But I don't think it will ever suffice.

(BTW, remember not everybody in the Community is talking in this discussion - there are big companies using SuiteCRM and saving tons of money in licenses, and not active in the Community at all... maybe they have the resources to help that you lack)

How can we bring in this extra potential that the Community surely has, without multiplying the resources we devote to Github? (We'd like to, but we can't).

I'd also like to hear your opinions on my proposals above about dividing work by modules...

Thanks.

[Mausino]

@pgorod we are here :) few of us try to active contribute how we can. This is reality.

Wait for miracle of big companies is insane. I know that is not "fear" that big company using/saving/growing with SuiteCRM but not contributing here (maybe in process with SA).

Maybe is time to add some loyalty members to this Github for management of issues.. Do you have some privileges label issues, add tags or something other.. ?

Irony is that number of users growing.. but active contributors decreasing.
As said @horus68

Alert: You are just loosing people doing what you are doing now.

When @salesagility don't change strategy of management of contribution. I aware its community will die as did in SugarCRM.

This ticket was created from flustration. On one hand we have great piece of software but on other hand it's close to be VERY BUGGY as was orginal SugarCRM before its died.

We want help. Nobody other is comming as we're cca 50 active users which make more as only opening issues. We're not full fledged developers. Everybody can do own part which like and it's good. I want test issues + i have many experiences with administration of SuiteCRM.. Give me tasks and i will do this.. But dont expecting for me unit test, or complex issue solving.

[pgorod]

Hi guys! We've already started discussing this thread internally, and I ask you to give us a few more weeks to fully "digest" it and come up with something. Thanks for your sincerity and especially, for your understanding.

[Abuelodelanada]

Hi @pgorod @samus-aran @Mausino @horus68 @gunnicom

I'm afraid that I agree with all of you!

We at gcoop have been working with SugarCRM CE and SuiteCRM for more than 10 years ... and we have developers with that experience.

Our commitment is such that we are SuiteCRM partners, even in a very difficult economic context for South America in general and for Argentina in particular. Anyway, we believe in the collective construction of software.

However it is a little frustrating to send PR and they are not approved. We have the certainty that when a PR fixes an error, it is approved, but if the PR adds a functionality or improves SuiteCRM, we know that it is very difficult to be approved.

We know that it is a lot of work for SalesAgility to manage such a large and growing community. So the question is: How do we help you better?
How do we make that developers with experience and commitment to SuiteCRM do not frustrate theirselves?

I have an idea that some time ago I told @samus-aran : Why do not we create a group of developers (maybe we can start with partners developers) that can do some of the work SA developers are doing right now in this github? Maybe this will reduce the bottleneck @pgorod mention.

Some time ago @samus-aran commented on twitter that they were starting the development of SuiteCRM 8.0, which supposes a very large re-writing of the application. How developers that do not work in SA to get involved in this development? I am convinced that many of us could provide valuable experience and code!

We are all in the same boat, do not let it sink!

[samus-aran]

Hello everyone!

Thanks again for your honest feedback and patience with us as we come together internally to tackle these issues you've all raised.

Now let's be real here and that we could go on a spiel about doing this and that! But I know that there are things that we have spoken about before and they just haven't came to fruition and that seriously is a huge frustration on our end too!
.... So I won't - we can talk big another time.

So rather than talking about all our big plans and ideas let's do this step by step and build the momentum. Of course were not going to get things right the first time but if getting those small wins knowing they only need polishing to grow into big, humongous wins then let's do it.

So, PRs. The bottleneck is testing. This isn't just for bugfixs but also enhancements. How to resolve this? We need more testers.. or we need more tests. But how do we obtain that feedback? Needs to be community, internally or out-source... Ideally it would be a balance but that isn't the case. How can we assist you the community in order to test awaiting PRs? How can we allocate more time to our internal teams to test? OK that is something we're speaking about right now and training newer members (you've probably seen them) to focus in that area.. OK I've said that more resources will be allocated but how can we really show that so everyone can see the rhythm? Well we do have metrics on issues closed and PRs merged we can easily demonstrate numbers on labels assessed, but will it just muddy the water or do we just keep to the number of PRs merged? In the latest release we posted the number of community PRs merged in the release notes which I think is important!

As I said, at the moment, I don't think making promises is as important just now as it is identifying why the bottleneck exists. Let's remove those road blocks and then we can see how many we get and go for as high as we can aswell as maintaining a high standard.

[gunnicom]

Sounds to me like "We will not change anything, but if there is someone who is willing to do some dirty work for us, that is ok."

[pgorod]

@gunnicom that's really ungrateful, maybe if you search your memory you can find a time when SalesAgility employees did some work _for you_, without you paying anything? Tons of it.

Please keep things positive here, otherwise we won't go anywhere with this.

[samus-aran]

@gunnicom Wow, really? That's a shame you took it that way. We are putting more resources to help with a particular area to elevate the bottleneck and you took that as.... we are not doing anything?

Where did you read "We will not change anything?" o_O Actually curious on that stance from my response...

But how do we obtain that feedback?

This was my attempt at a rhetorical question, but feel free to extend a better way to provide testing feedback. Do we need to set up time dedicated to communication specially around Pull requests ? live sessions, regular announcements via mailing lists etc etc.

Needs to be community, internally or out-source... Ideally it would be a balance but that isn't the case.

Do you not agree there should a be a balance? We all know it isn't a balance, what side you are seeing it from?

How can we assist you the community in order to test awaiting PRs?

Following up from the idea of having an equal balance, it was mentioned earlier that tests are hard and we understand that. How can we make it as easy as possible to remove that block.

How can we allocate more time to our internal teams to test? OK that is something we're speaking about right now and training newer members (you've probably seen them) to focus in that area..

So we have invested back into the Product team specifically to target testing, code review and assisting the community. They are still being trained so they are on that steep SuiteCRM learning curve but you'll see that over time.

OK I've said that more resources will be allocated but how can we really show that so everyone can see the rhythm? Well we do have metrics on issues closed and PRs merged we can easily demonstrate numbers on labels assessed, but will it just muddy the water or do we just keep to the number of PRs merged?

Proof is in the pudding as they say, so our question was how can we demonstrate that things are progressing? Are these metric on the release notes good enough?

As I said, at the moment, I don't think making promises is as important just now as it is identifying why the bottleneck exists. Let's remove those road blocks and then we can see how many we get and go for as high as we can aswell as maintaining a high standard.

Perhaps I wasn't as clear as I had wanted to be. We are not making promises on "We will merge in X amount of Community PRs in a release" at the moment in time because lets focus on removing road blocks without compromising on quality and striking a suitable balance of PRs accepted and quality assured.

[Abuelodelanada]

Hi @samus-aran thank you very much for the feedback! I really appreciate the work all of you are doing.

So, PRs. The bottleneck is testing. This isn't just for bugfixs but also enhancements. How to resolve this? We need more testers.. or we need more tests. But how do we obtain that feedback? Needs to be community, internally or out-source... Ideally it would be a balance but that isn't the case. How can we assist you the community in order to test awaiting PRs? How can we allocate more time to our internal teams to test?

Ok, let's try to reduce this bottleneck.
Just thinking in loud voice:

• Is it possible to assign/tag the issues that needs testing to a group of people from the community to help doing this work?
• The tools provided by github.com are enough to a growing community like this? May be we could use an external tool to organize ourself (a mailing list*, an IRC channel, a particular forum, a slack channel, a Telegram group, etc)

I think we have a lot of hands but we should try to organize this force in a more efficient way.

* Yes, this old militant for Free Software still uses mailing lists :-P

[samus-aran]

Thanks @Abuelodelanada for your suggestions!

• Similar to the 'help wanted' label? My only apprehension on using that for PRs would really be that we would invite all to test whether or not it has been internally tested. I think the 'help wanted' would be best suited for issues. Couple of questions here: What about the currently used 'Fix Proposed' is this clear enough for users to that they can provide feedback and test the linked PR? From the PR list is the current label "Requires Testing" clear enough? The label "Assessed" indicates that it has been tested, so would have that not appended to a PR indicated that it still needed to be tested?
• We are currently looking at a few things like the im channel, dedicated events so that is certainly in works as we speak - something in the coming weeks! As with the original topic of milestones, would that also help with providing focus to people who wish to test?

[horus68]

Almost all users here are regular opensource collaborators. SuiteCRM can be considered as a special case as it is a company software, not a community software. Its also not a company software with a community version.
That usually causes issues between the community and the company usage.
In the end S.A. merges PR when they need it, not if "all" the community needs it. We ended up with more the 200 PR around, most of them will never be merged. Most are now useless because they are incompatible with new code. And nobody can ask the initial users to recreate it, its unfair.

And unless you separate the company version from the community version it will keep on like this. That's what we get here, and that's life.
This is not a rant, its my perception of the implemented system: even if SA do not want that effect, its an actual side effect.
In top of that there are also some issues on actual SA work: there are many PR created by SA people or accessed by SA that are not merged for many months. They are total time lost and you should have spent your time in something else.

Note: I don't mind you don't have too many hours for the software, I can't pay SA for what I would like to have in the software. I'm also not a coder so I accept what I get.
What I need to know is the plan for the future and how things are supposed to work

Things to be solved:

1- Instead of focus in tools and systems, pick a paper and pencil and lay down a workflow for the software support. Your workflow, not "ours". You will find that most of the problems in software companies can be reduced when people organize things with a pencil, not with another software!

2- There is no point of asking help to test PR if they are not planned to be merged in a near future. Else you don't get people to test any other PR. You can find many users here that stop sending PR because they don't get any attention.

3- In a community software, the usual workflow is:

• someone post a PR
• then X number of successful tests are required,
• a power user needs to approve it
  ... and then it get merged.

4- People need to know if a PR marked as X or Y is a path to follow or to drop. If that is intended to be used in the near future or never to be used. Also its ok to say now one thing and later change your mind, not having a say its the worst case scenario.

5- when using tag system for PR... what is the workflow. I its "In review" more near the end then "Need tests". Things should be more explicit, like a number in front of the tag so we can know in what stage is the PR.

===== Personal note: Kanban system, with tasks organized in columns from left to right - where they will be closed as solved - can help organize things in GIT... even if you use some card paper system as I usually use in my office before turning on my computer!

[horus68]

And I didn't talked about the issues backlog, only about PR!

On the events... it would help, even if it will not start with many users, because you need to gain confidence from the users. see this event for Joomla: https://docs.joomla.org/Pizza_Bugs_and_Fun_2018_Germany

or see some others with similar problems:
How to deal with bugs in sprints -
https://community.atlassian.com/t5/Jira-questions/How-to-deal-with-bugs-in-sprints/qaq-p/284621
https://community.atlassian.com/t5/Jira-Software-discussions/How-to-manage-bugs-which-open-during-active-sprint-w-o-impact/td-p/648476

Managing Bugs in Scrum and Agile Projects
https://www.mitchlacey.com/blog/managing-bugs-in-scrum-and-agile-projects

Testing in Agile: A Quick Tutorial on Defects, Bugs and Everything in Between
https://www.linkedin.com/pulse/testing-agile-quick-tutorial-defects-bugs-everything-between-sherman/

4 Agile Ways to Handle Bugs in Production
https://www.sitepoint.com/4-agile-ways-to-handle-bugs-in-production/

[pgorod]

Ok, so have a look here for the upcoming PR Party! 🎉

https://suitecrm.com/suitecrm-7-11-announcing-pull-request-party/

[pgorod]

And meanwhile, reading Horus68's comment I have an idea/suggestion.

We currently have the milestone which we're trying to use more consistently, as requested by Mausino. It looks like this:

https://github.com/salesagility/SuiteCRM/milestone/6

But GitHub also provides a different tool called the project, which has a nice Kanban:

https://github.com/salesagility/SuiteCRM/projects/2

So my suggestion is that we create a GitHub Project for the upcoming milestone (release), and put all those cards in a Kanban. This let's us organize work in a way that is visible to the Community. Our most dedicated developers (and other people who help in other ways) from the Community would try to make themselves useful around that work.

One advantage is that people would know that any work done there would have immediate effects on the next release.

[Abuelodelanada]

Hi @samus-aran

Similar to the 'help wanted' label? My only apprehension on using that for PRs would really be that we would invite all to test whether or not it has been internally tested.

I think that if a PR is tested by some community members, then the internal testing should be lees exhaustive.
I trying to think about a workflow that reduce the hours in testing for SalesAgility, a workflow to reduce the bottleneck.

(Always thinking in loud voice) What about if a PR needs the OK from 3 community members? May be, if that happens, there is no need for internal testing.

I think the 'help wanted' would be best suited for issues. Couple of questions here: What about the currently used 'Fix Proposed' is this clear enough for users to that they can provide feedback and test the linked PR? From the PR list is the current label "Requires Testing" clear enough? The label "Assessed" indicates that it has been tested, so would have that not appended to a PR indicated that it still needed to be tested?

The labels are very good, the problem I see with using only that is that it is not possible to keep the community cohesive. That's why I thought of a communication channel (At least, mail that let you know you can help in a PR because someone assigned to you or assigned to a group)
To be able to collaborate with SuiteCRM it is necessary to enter every day to github ... and if you can not do it, you do not know what is happening.

[Abuelodelanada]

Ok, so have a look here for the upcoming PR Party! tada

https://suitecrm.com/suitecrm-7-11-announcing-pull-request-party/

Awesome!!! We'll be there!

[Mausino]

@salesagility @samus-aran @pgorod that’s great news 🙂 PR Party! (Hope that doesn't will last one)

I hope you’ll build some nightly demo version of SuiteCRM based on branch to which will the changes merged and will them show on hourly bases that will possible test them.

Also will appreciate if will possible have admin part in this demo, because many issues are also related to admin area, which isn’t possible test on current demo yet. (as has admin interface the softaculous demo https://www.softaculous.com/softaculous/demos/SuiteCRM )

Also i didn't expect that one thicket will explode to this new changes so quickly. But i am glad that i now know that i didn't feel alone the frustration 💛 and things are moving forward in right way 👍 because we discuss and try to find together the solutions how improve the software SuiteCRM which of many of us is daily part of work life.

[samus-aran]

Just to say thanks again for all your feedback!

Most are now useless because they are incompatible with new code. End nobody can ask the initial users to recreate it, its unfair.

Agreed @horus68 it is unfair. At a time we did ask for such a thing but we saw that was a cause of friction so now we don't expect people to do it unless we feel they could benefit from the tutelage e.g. learn how to make unit tests or how to conform to best practises (within limits). If there is a PR that does have this issue then we will help to bring it up to the same version it is now. If we can't do it immediate we'll add it to the queue and allocate it to one of the trainees of the product team as a learning exercise.

And unless you separate the company version from the community version it will keep on like this. That's what we get here, and that's life.

I get where you are coming from @horus68. Though I don't think this is about versions (I'm assuming you didn't mean vision?). Our biggest challenge is that we haven't been as visible in our limitations with the community to assure there isn't a drastic 'difference' in vision. As everyone knows we are a business, but I don't think that means we can't grow in parallel with what the community wants but I agree it can seem like that we are not merging because of differences of opinion but that isn't the case but majority of the time down to resources and time. But point taken that when we do close either suggestions or PRs that it is a decision out of time allocation and perhaps state to the community if they pursue the suggestion that we would merge it in. We should be more clear cut than we are currently are leaving people unknown if we or the community will pick up the task.

SA work: there are many PR created by SA people or accessed by SA that are not merged for many months. They are total time lost and you should have spent your time in something else.

Again I can't agrue with that and that is something myself and Matt are working hard to elevate the code lost between product and project team.

Note: I don't mind you don't have too many hours for the software, I can't pay SA for what I would like to have in the software. I'm also not a coder so I accept what I get.
What I need to know is the plan for the future and how things are supposed to work

Thank you @horus68 for your understanding I personally very much appreciate that. We are not perfect and having a fully open source software and self funded is a very challenging hill. As I stated earlier we can keep talking about big plans but I think doing things would be more benefital to learn and re-try. So if I may ask for a little more patience on finalising these plans for all areas and work together on applying small but constant changes.

All your points are great and I think Jose also voiced some of them. I think the most immediate action first would be determine the workflow of the PRs - how we envision it and publish it and open up to the community to comment. I love infographics so we can sketch it first (I too love pencil & paper!) and include that to help members to visual. I'll see what I can do in the coming days.

So my suggestion is that we create a GitHub Project for the upcoming milestone (release), and put all those cards in a Kanban. This let's us organize work in a way that is visible to the Community. Our most dedicated developers (and other people who help in other ways) from the Community would try to make themselves useful around that work.

Just so everyone is aware that internally here at SA we use Tuleap for our sprint boards and although I love to have a single board I don't think we will have this due to security issues that need to be dealt with internally and other non public tasks. So there may have to be a disclaimer that we aim to achieve tasks allocated to a github milestones/projects but we do have other tasks within the same sprints that we can't fully disclose and may take priority. If that isn't as such a huge issue to the community then I don't see why we can't have this structure on github (though might be a pain internally ^^; We'll have a look at a suitable github plugin for tuleap).

I think that if a PR is tested by some community members, then the internal testing should be lees exhaustive.
I trying to think about a workflow that reduce the hours in testing for SalesAgility, a workflow to reduce the bottleneck.
(Always thinking in loud voice) What about if a PR needs the OK from 3 community members? May be, if that happens, there is no need for internal testing.

Yup, yup yup. We have always said internally that if there are at least 1 or 2 community members tested the PR (depending on the PR, the complex or fundemental change requires higher number) then be more inclined to merge it. That is why we try and ask the OP of the issue to test the PR if they are able to. https://github.com/salesagility/SuiteCRM/issues/6351#issuecomment-444948572

The labels are very good, the problem I see with using only that is that it is not possible to keep the community cohesive. That's why I thought of a communication channel (At least, mail that let you know you can help in a PR because someone assigned to you or assigned to a group)

Perhaps that worfklow that @horus68 suggested would be a benefital start with queries to aid people what is the latest to test or review. Regards to the communication channel that is something we want (I want really) so I'm keen to discuss this perhaps if that is something we can next look at as I feel a direct communication really brings issues to the surface if we are talking about them actively.

hope you’ll build some nightly demo version of SuiteCRM based on branch to which will the changes merged and will them show on hourly bases that will possible test them.
Also will appreciate if will possible have admin part in this demo, because many issues are also related to admin area, which isn’t possible test on current demo yet. (as has admin interface the softaculous demo https://www.softaculous.com/softaculous/demos/SuiteCRM )

We actually had (temp brought down for the 7.11 demo) a nightly build and announced it on the forums https://suitecrm.com/suitecrm/forum/announcements/20304-suitecrm-nightly-build-instance. Did anyone use it as we didn't get any direct feedback? As I stated on the blog post that we will look at that bringing it back up for the event and see if it can be updated down hourly, but it was previously updated every day at 6pm GMT ish.

Regards to the admin section we are looking at that though how quickly we can provide that I can't give an ETA just yet.

Also i didn't expect that one thicket will explode to this new changes so quickly. But i am glad that i now know that i didn't feel alone the frustration yellow_heart and things are moving forward in right way +1 because we discuss and try to find together the solutions how improve the software SuiteCRM which of many of us is daily part of work life.

Agreed! Thanks everyone! I'm not going to close this issue until we have formalised a little more of these processes or have a better thread to discuss (potentially the direct communication).

We'll announce more of the PR party either today or tomorrow at the latest so we can prepare everything for a very busy (but fun!) two days next week ;)

[Mausino]

@samus-aran i know about nightly few months but on 90%of time which i tried to check it was this page off :( this reason why is so hard test it

Chrome version 70.0.3538.110 ( (64-bit)

[samus-aran]

Hey @Mausino

We actually had (temp brought down for the 7.11 demo) a nightly build and announced it on the forums https://suitecrm.com/suitecrm/forum/announcements/20304-suitecrm-nightly-build-instance. Did anyone use it as we didn't get any direct feedback? As I stated on the blog post that we will look at that bringing it back up for the event and see if it can be updated down hourly, but it was previously updated every day at 6pm GMT ish

Yeah its down right now and has been since 7.11 beta was released, but surely wasn't before then? Did we note it anywhere i.e. on the forums that it was down :cry: I'll discuss internally if we have records of it going down but your current screen is as expected for the time being.

[pgorod]

Details about the event here:

https://suitecrm.com/suitecrm/forum/announcements/21245-17-18-dec-suitecrm-event-pull-request-party

[samus-aran]

Thanks Pedro for posting that.. We would :heart: your feedback around the upcoming event. Does it sound interesting? Is it clear enough, what do we need to support it more to encourage more to join us next week? We do have a few things to tackle today to add more to it but we have also scheduled time to progress other points in this thread. :+1:

[Abuelodelanada]

@samus-aran

Sounds super interesting! I hope this event will be the first of many, including a coding sprint in Stirling ;-)

What communication channel we will use?

[horus68]

It sounds like a well-planned event, and I expect to be present even if it's just to test a PR, as I think these types of initiatives require many users to get involved and collaborate.
Just do not expect too much from the community in the firsts events (especially in the second and third event), because any new approach with a group needs time to establish itself and be really useful. And perhaps this process begins starts by looking more time-consuming for SA than if they continue to work as it has until now. Over time, I am sure that more people will come and then, it can turn out to be a great tool for SA in the evolution of SuiteCRM.

[samus-aran]

Thanks @horus68. Point well made. Its like previous comments were made, steps need to be made to increase momentum and autonomy in a large project like this so yes, lets try different things and see what works and encourage more growth and collaboration.

BTW you are all invited to the gitter chatroom! Speak to you there!

https://gitter.im/suitecrm/Lobby

[thomashallam]

been doing user research around software for 10 years, it's pretty clear you need two distinct backlogs - one for bugs/patching and one for new ideas/enhancements.
You need someone to run strategy/planning for both of those lists and don't commit to introducing loads of new ideas/enhancements unless you are sure they add value for users, align with some project vision, and are in scope/achievable considered the available resource.
Suitecrm is a great project but it needs to be stable to be useful. With regards to having more regular upgrades / hotfixes this is a problem and time consuming for less-techy savvy users, perhaps a streamlined backup/fetch-auto-upgrade option would be helpful and more automation testing around the frequent upgrades. also maintaining fewer versions would speed things up too

[samus-aran]

Thank you @thomashallam for your feedback!
I completely agree and we tried to do that by separating new ideas onto Trello and that fell to the way side again down to resource (plus didn't help me leaving for mat leave). So we are keen to get that up and running again on a stable and more long term platform.. we are looking at discourse as our permanent solution for forums and perhaps utilise that structure as a way of bashing out suggestions to firm ideas that can be have milestones and timelines. Once those suggestions have structure we could potentiality move them back here for those taking the responsibility to develop. This idea also falls inline with us wanting to use Github as a smaller project management tool for minor releases and community related features/suggestions.
Regards to the strategy on alignment, yes, we need to bring everyone on board on what are the bug fix priorities for the next releases. The community team have had a few discussions about this and how we can do this in a github fashion - e.g a place that people can easily identify as for the next milestone and if people are willing to share tasks out to achieve that goal. Hopefully we should get that experiment up and running soon and see how that progresses.
We are looking at auto-upgrading as a way to help our internal teams at the moment but we do feel abit like fire fighting trying to resolve travis which we're finding more of a hindrance at the moment. But we definitely take your points on board.