Discussion: Understanding ISPConfig

Discussion in 'Developers' Forum' started by TonyG, Oct 23, 2020.

  1. TonyG

    TonyG Active Member

    I understand that ISPConfig is designed for a specific use-case. Over the last couple days I've been reading a lot of forum posts where people ask about how to do specific things with the software. One example is Client-level access to multiple websites, about which I opened a ticket recently. I didn't post that without having already done a good amount of reading and today I was reading even more.

    In my ticket, I'm trying to get a final, definitive answer to a user problem that has existed for a decade. I'm not necessarily asking for a change to the software. I'm asking for "an answer" which could come in the form of documentation, which I would gladly write. (Please do not respond to that specific example. That's not the topic here. It's just an example of many threads that seem to repeatedly rehash the same topics in different ways.)

    I think what's happening with that example topic and others is that there are a number of undocumented core principles related to this product, understood by developers but not communicated to others. Without that basic understanding, newcomers continue to ask questions about doing things outside of that scope. That just results in numerous forum posts all dancing around the same topics, lots of "don't do that" "it doesn't work like that" responses, and I'm guessing some amount of aggravation by developers about why people don't understand that the software simply doesn't work like that.

    I think a solution to some of these FAQs is for some doc pages, um, FAQs, that step back to address the specific environments, use-cases, and activities for which ISPConfig is targeted. This will result in a different approach to a number of questions: "Go read these pages to understand how it works, read the suggestions, see what other people do, and if none of that applies then you can write an addon or use something else."

    So related to this Developers' Forum, I will ask you guys : Am I getting this right? Do you feel like there are too many people who simply don't get it? Do you feel like you're answering the same questions stated innumerable different ways?

    Yes, yes, we're always going to come back to "people don't read FAQs before asking questions". In recent discussions we have already moved beyond that. We're going to have new docs, and that will allow you to cordially direct people to the M for people to RTF.

    What I'm asking here is for you to really step out of your own shoes for a moment and tell us if you get the impression that there might be something about how this software works that is not intuitive. At some point maybe a light came on for you, and now questions that don't fit that model seem kinda stupid and aggravating? @till said this recently:
    That note was interesting to me because it was a response to my simple statement that ISPConfig is difficult to understand. That's my opinion. It's the opinion expressed in various reviews. Till's response, sorry man, was defensive with a pre-canned explanation for why people say ISPConfig is difficult to understand. I know what Plesk is but I've never seen it. I didn't mention Plesk or any other software. I was just talking about this software. "Different approach"? Different How? Is ISPConfig really different like Windows, macOS, and Linux? I had no idea. I feel like I'm missing something. That's what this thread is about - what do you mean by "approach to split services"? What do you mean by "logical approach" and "group functions"? Maybe if you can articulate this underlying concept about how ISPConfig components fit together in some cohesive way, the rest of us might get a better understanding of what to expect, and not.

  2. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    There are questions that are duplicates, e.g. a lot about "where is the APS installer?" (not only on the forum). It is clearly stated in the release notes that APS is removed, but people don't read it. Just noting that.

    We know that the panel can be confusing for non professional / unexperienced users and we are brainstorming about the best way to change that.

    Most of your posts seem to about the lack of docs. We already agreed about this and are working on the manual system. You have made your point and I think most people agree with the core of it. The problem is that we (devs and contributors) work on ISPConfig in our free time, and sometimes other things get our priority. And even if we have the time to work on the project, some bugs require our attention. When ISPConfig 3.2 is more settled and some bugs are fixed in 3.2.1 (and eventually 3.2.2) we will probably have more time to work on other things like the docs. I will probably take that on.

    There are never too many people that simply don't get it. I am dev and moderator on this forum because I like to help others, wether they are starting their journey in the hosting world or they have been here for 30 years and still don't understand the difference between postfix and apache (jk ;))

    As stated earlier we know ISPConfig can be confusing for some users and we are thinking about the best ways to change that. But overall I don't think ISPConfig is more difficult / easy than other panels. I have loved ISPConfig since day 1 because it was so much better in my opinion than Plesk, DirectAdmin, CPanel, etc. Yes, I saw some shortcomings and have worked on those myself. I did quite some contributions to the UI to make it clearer to end users, so it's not that we forget about the end users and only work on internal functions or something.

    Lastly, I want to make one more comment. This is my own opinion, not one of the devs / staff of the forum, and I don't want to offend you. You have posted several big threads and I really appreciate that you are invested with the software. But keep in mind that some devs pour their heart and soul into this software and you keep critizing it - sometimes for a valid reason, sometimes not (again, imo). That is frustrating and makes me think twice before I consider your ideas, while some of them are really good!

    I hope we can start on the docs / manual project soon and that we can work as a team on that. My idea would be that we have a separate GitLab project for this where you and others can open issues to discuss eventual changes on the manual. When we agree, a MR can be created, reviewed, and merged.
    TonyG likes this.
  3. TonyG

    TonyG Active Member

    No disagreements, thanks man. To be clear, I have no intent to criticize at all. I tend to be more direct with developers, point out the elephant in the room if there is one, and often try to draw attention to higher level issues that get lost in day to day activities. If there's no elephant, so be it. It's good if someone asks. This comes from my background as a business owner, product manager, QA manager, marketing guy, and as a developer who is passionate about getting more people to use great software. Yeah, I have other work to do too. I'll lighten up on the introspection. Thanks.
    Th0m likes this.

Share This Page