FreePBX design discussion

I believe it basically does nothing when unlicensed (I could be wrong) so there would be very little motivation to remove it I would think.

I could see this being considered a bug. The dialplan probably shouldn’t generate when unlicensed.

Most commercial module functions simply “return” if they are unlicensed. In “theory” an unlicensed module should do nothing. It may be worth filing a bug for. Not sure how much priority it would give.

It is harsh. We can’t stand 4PSA’s Voipnow and for the time-being still have tons of extensions left on it. We thought Voipnow was great until we properly got to grips with the FreePBX GUI on a full time basis, and we absolutely love it. Those using it all day every day might have a very different view to those playing with it for fun on Sunday afternoons. It pays the bills and for business use it’s better than most, IMO.

2 Likes

Agreed. For those that know it, it is perfectly serviceable. For those that use it all the time, it does take 2.5 times as long to configure a new system than it used to, primarily because of changes that were made in the last 5 years. However, the GUI is not intuitive to new users for the reasons I’ve discussed.

The fact that I’ve complained about the GUI does not mean that I think that it is terrible. The FreePBX GUI is not terrible. However, like most things, it has room for improvement.

2 Likes

I don’t think he is calling them lazy. At least I couldn’t find where he was calling them lazy. I think he was just pointing out that in today’s world programmers are not expected to just create source code. They are expected to do documentation beyond just what is required to commit your source code the cms. This doesnt speak to laziness but to a historical way of thinking and honestly a tendency to neglect documentation if not managed by the manager of the repo. If the FreePBX development mindset was to change or if the repo manager was to stop allowing commits without adequate end user documentation, then it would benefit everyone from a usability and adoption standpoint. However we do have to acknowledge that there are only so many developers. Adding this requirement would mean features will take longer to get released as the developers will have to dedicate some of the time that is currently spent programming to do this documentation. A change like this may also have implications on personnel. What if their best programmer despises documentation? Is it worth potentially losing their best programmer? We dont see what is going on inside the organization so this we will never know. But we have to at least acknowledge that this change would have an impact both positive and negative.

1 Like

I agree 100% with Kirk. Like many people who are on the autism spectrum, I say what I mean. There is no need for you to search my words to find hidden meanings. If I thought you were lazy, I’d use the word lazy, and then give specific examples to support it. Since FreePBX is now a corporate sponsored project, the issue here is about allocation of resources. It has nothing to do with personal characteristics.

And since I’ve been accused of calling the dev team lazy, let me meander just a bit. I know for a fact that Andrew Nagy is a hard-working and brilliant programmer, and I have never, ever intended to communicate the opposite. The fact that I disagree with some of Andrew’s decisions does not mean that I think any less of him as a person. We should all be able to agree to disagree. Also, please don’t infer anything negative from the fact that I only mentioned Andrew here. I mention Andrew because he is the only former dev who is particiating here who I have spoken with one on one.

Getting back to the point: It’s not hard to understand how FreePBX got here. When started as an open source project, the coders were writing FreePBX for their own benefit, i.e., as hobbyists. They knew how it worked, because they wrote it. If others found it useful, that was great, but nobody was expecting that FreePBX would become a commercial product. When nobody was funding the project, and nobody expected to sell it, there was zero reason to spend much time on documentation.

Now that FreePBX is a corporate sponsored project, I’m saying that there’s a good reason for Sangoma to allocate more resources to documentation. I agree with everything that Kirk said on this point.

But, in addition to what Kirk said, there is another benefit to having documentation precede GUI changes: It helps to ensure that the GUI stays friendly, easy to use, and avoid unnecessary radical changes.

Forcing someone to think about how to explain a change in writing ensures that the change stays simple and user friendly. The simple changes are simple to explain. If a radical change required radical changes to the documentation, a dev might work harder to find a way to accomplish the same thing without the radical change.

Between the 5,000,000 words he has put in this post, many of his posts have 5-10 edits, short of screenshots and some sort of machine learning it is hard to know what he is saying.

There have been countless complaints about the documentation. The documentation is dare I say as good if not better than it has ever been. I spent over 7 years formatting, cleaning and adding to the documentation. There is a team of QA and internal testers that also update the docs. At one point a staff person was even tasked to proof reading and going through all the docs as a layman. She held a non-engineering position with the company. (engineers at least in our realm tend to suck at spelling and grammar)

The complaints are that the devs are not spending time updating docs. That is true but there are people who are paid by Sangoma that are.

The process.

Developer makes a thing. He roughly puts together a design/use doc.
QA person uses that spec to test things, open bugs and write end user documentation.

  1. The average person never looks at the wiki unless someone directs them to an exact page.
  2. The average person doesn’t search these forums or google for the answer to their question. They make a fresh post asking the same question for the Nth time.
  3. The average person who has no issues will not come to the forums or the wiki.

There has been a lot of time making sure #3 is the normal. No news is good news. You can lead a horse to water but you can’t make it drink. There will always be #1 and #2. They are the ones you will see here. That is why the productive forum members typically answer the same question for the Nth time. It has nothing to do with the availability of docs or answers.

There use to be a lot of toxic people here and still in IRC. These folks are the LMGTFY types and the RTFM types. Honestly if there is one type of person any community can lose it is those.

The same person has been making the same baseless complaint any time they get an opening for years. A bunch of nonsensical unformulated pages that covered doing random things to a FreePBX version that was end of life got replaced by proper documentation about how to actually use the modules of current releases. Since then that person has even asked for my job because his law degree gave him some entitlement to do so. That my friends is the history of documentation in FreePBX.

A GUI is like a joke. When you have to explain it, it isn’t that good. The UI over time has been changed to make sure there is no need to leave the UI to know why something is there.

The wiki is underutilized much like google but is well maintained.

You will note there are never any specific examples given, only ever hyperbole and venom.

And he hates being called out.

1 Like

Many of my edits were required because TheJames and others are flagged my posts, causing the system to hide them until I edited them. In other cases, I edited my posts to improve them. I’m not sure why anyone feels the need to read the old versions or compare them with the new ones, but you’re certainly welcome to do that if you’d like.

Since the TheJames and Sorvani have turned this into a series of irrelevant and mostly false personal attacks on me, and the mods have declined to do anything to do stop them, I’m leaving what has (except for their participation) been a very constructive discussion of the design elements of FreePBX.

Good luck everyone. :slight_smile:

This is excellent! I don’t think @AdHominem or any of us would not recommend this. I think one of the main points he is trying to make is just there is a different workflow that may help improve the documentation. He isn’t saying that you have to do it just that you might want to consider it, as it could improve things. It is possible he has seen it improve things of this nature. I know I have seen it, thats why in my last company those writing the code is required to document it and in the code review both the documentation and the source is reviewed. Now there is a documentation specialist that goes through and independently makes incremental improvements, but their contributions are different from someone who so intimately knows the code and what it does.

I can only speak for me and the IT people I know, but I don’t know any IT person that doesn’t do some research in an attempt to solve a problem before they post on a forum. Now some people aren’t as good at google or when they see a post on a topic they wonder if it applies due to some reason or after trying x,y,z that was on the post they still were not able to solve their issue.
So there are very legit reasons to post in the forum for a topic that has already been covered.
Additionally most admins I know do at least some research before setting up a new system. The absolute first place one would go is to a quick start manual which is on the wiki.

1 Like

OK so I’m going to throw this into the and see what backlash I can over it.

Can we, for future releases, make sure that all the key, driving and spotlighted features of the release actually work when the release is done? I mean v15’s driving features where an overhaul on Backup/Restore and GraphQL. As I’ve seen there have been some issues with Backup/Restore but what really concerns me is this:

Now these were all comments in the last week or so. Which says to me that 2.5 months after the stable release of v15 50% of the key highlight features of the new version isn’t even fully ready and what does exist has bugs in it. It also appears to not have completely internal reviews.


Now that isn’t to say I’m not being positive and hopeful with all the new changes that have happened at Digium/Sangoma. I know some things are happening to show that Sangoma is committed to this project and the community and I’m a 100% cool with that. Just do it right. Quality over quantity is always the better path.

Reported issues for the backup module in 15 are assigned a very high priority and reports of issues have slowed noticeably since initial release.

The API module is different in that it’s purpose is to be an API framework that all other modules can leverage and ultimately become a comprehensive, system wide API interface. As far as I’m aware, the framework itself is solid, but at present many modules have yet to be updated to hook into it. This is not a path to a door, more of a journey to a horizon, and something the coding community can assist with.

2 Likes

I disagree with the statement that Quality over quantity is always the better path. I really think it just depends on what it is. Should we invest time and effort into SIP and backups? Yes, that should always work and should have 100% quality! Should we spend a bunch of time and effort making sure the GraphQL library is complete and works 100% of the time? Probably not so much, since it’s probably a feature that less than 5% of the users actually want to see. The fact that it took 3 months for a bug to show up is evidence that GraphQL may not be a feature that is needed.

I would rather invest quality time and effort into the things that matter and then provide a framework for new features that maybe a bit experimental but help to push the project forward. Otherwise we will be spinning our wheels trying to make everything perfect and new features will never happen.

Now, I’m not saying quality isn’t important. We have a lot of internal efforts centered around unit testing and process revamp that is geared towards better quality software. My point here is that some modules we can afford to be more risky with (GraphQL), while others we can’t (Backups).

2 Likes

Code contributions are always welcome.

2 Likes

Another little tidbit to throw into the hat on this thread because of what I am seeing on the forum right now. I’ve said it before and I’m going to say it again. Stop sending every single user to the Edge Repo for a fix. That’s not what the Edge repo was made for, it’s not how it is supposed to be used. So please stop doing it this way.

The Edge repo was meant as a place for modules to go when they are still passing review and QA which means they haven’t been approved for STABLE release yet. They could still have bugs, etc… The Edge repo was meant for users like me (and those like me) that have the skillset and knowledge to deal with an edge module having bugs and issues with it still. We understand it, we accept that fact.

Right now as of this post, people are having issues with updates that the answer is now “Oh get the new version of Framework from Edge”. No, if the current version of Framework in the Stable repo is flawed and broken either pull it or make this new release of Framework stable and put it in the Stable repos. Now if anyone wants to comment on how that isn’t prudent and provides reasons why, just understand you’re only backing up my argument that we shouldn’t be throwing Edge repos out to every basic user out there as their go to answer.

All this is doing is training users that if their fix isn’t in the Stable repo they should grab it from the Edge repo. Except at that point the Edge might not have the fix and might even cause more issues for the user because of other changes (not saying bugs but the IVR overhaul is a good example) that they are unaware of.

1 Like

Absolutely right. Someone released a bug direct to stable so it’s best to fix it directly in stable.

When users post an issue I know to be addressed with an edge version, I advise them to upgrade. That is the case with my colleagues as well. Users have the choice not to upgrade and live with the complaint, does that need to be stated every time?

The latest case was an error on our (Sangoma’s) part where a module was published to stable while a dependency was still in edge. Obviously the proper fix is “don’t ever do that”, but mistakes do happen. In this case it was identified early Friday, and the fix was published to stable early Monday (today) one business day later.

The ONLY practical fix to this current issue previous to today was to upgrade framework to edge. So I ask in seriousness, given these specific circumstances, what should have been said if not upgrade framework to edge?

2 Likes

While I totally agree with your opinion of don’t tell people to update to edge, it is the only simple method currently built into FreePBX. There is no simple way to revert a module back a version because the version numbers are obscured. Yes The can be looked up, but it is so many clicks.

In this specific case, the problem had nothing to do with Framework, technically. It was Core that was released and has a dependency on the unreleased Framework. This Core version should have never been released. That or if it was released, it should never have let itself be installed if Framework was not at the right level

Once it all went to shit on the forums here and was a known issue, there should have been no reason for a 3 day lag. Business days mean jack squat.

Depends on one’s definition of simple. Module version numbers are not obscured, and rollback to any of the last several versions is supported in the GUI:
https://wiki.freepbx.org/display/FPG/Module+Admin+User+Guide#ModuleAdminUserGuide-Rollback

That is why I stated “so many clicks”. It is a lot of work to get to compared to your normal

fwconsole ma upgrade modulename --edge
fwconsole reload

There are plenty of plugins to make the Confluence experience cleaner for documentation users. k15t’s Confluence Viewport is one that immediately come to mind.

I am no technical writer but it seems the wiki was built with a focus to document in a more archival sense rather than a focus to provide a gateway to documentation.

1 Like