Following both the Suggestions forums, there is often heated dispute about whether or not to have X feature as an admincp option as core, or fully integrated.
One way to approach this is via the moral or social issue.
Some of us want feature X left well alone because they/ we don't see it as necessary.
Some feel that it is fairer to add a feature X as an admincp option and leave it to us as admins to enable/ disable according to the needs of our boards as we see them.
I very much belong to the second point of view. The major thing that got me choosing the forum software I did choose, years ago, was how many options it offered me that fitted my needs.
I was also seduced by the lovely modding community.
But I discovered that mods can be a pain over time because sometimes they just don't work; getting changes made as my board needs changed has been difficult or impossible - mods got too busy to help even if paid, or disappeared all together. (An honorable exception was Logician who hangs in there updating, and providing advice on adaptations way beyond the call of basic duty.)
Upgrades can be a mess for a lot of people I understand.
So the oft repeated cry "you can mod it" is not at all the ideal solution, at least not reliably.
If you're a coder you can. If you're lucky and get a good coder for love or money, you can. But many of us can't, don't have enough time or energy from our many projects to learn, and can't find reliable coding support.
So, back to the core, the integrated stuff.
It would be helpful to understand a bit more what the pressures are about this. I'm beginning to understand that it's not so simple as just adding on things so admins can choose.
People talk knowledgeably about "bloat." The concept is intuitively understandable to me, but only superficially.
I thought it would be useful for me and quite a few others to open this up and educate us more on what "bloat" is about.
Then we'd be able to be more mature clients, with a bit more judgement skill on when asking for X, Y and Z is less or more of a problem to actually do for the team.
SAMPLE QUESTIONS
These might not be the way you'd approach the subject. But they illustrate the kind of mindset of a non-coder admin.
~ What kinds of functions are the worst criminals re "bloat"?
~ What kinds of functions are reasonable re "bloat"?
~ Are there other considerations where feature X actually cuts down on a mass of stuff - shortcuts it - so if it adds in another way there can be a net gain?
Another way of putting it is
~ What kind of [Suggestions] are welcome as comfy to put in?
~ What kind of [Suggestions] are an unwelcome sight because they look simple to us non-coders but they mean headaches for the team? (or a modder)
LATER: Then there's "plugins" which seem to be a halfway house between "core" and "mod."
I just thought if we admins who are not coders could understand the developers point of view just a bit better we could be more considerate and not waste time with unworkable ideas.
Of course some of this will be unpredictable - it depends on a lot of factors - kind of thing.
But surely it should be possible to explore at least some outline guidance.
One way to approach this is via the moral or social issue.
Some of us want feature X left well alone because they/ we don't see it as necessary.
Some feel that it is fairer to add a feature X as an admincp option and leave it to us as admins to enable/ disable according to the needs of our boards as we see them.
I very much belong to the second point of view. The major thing that got me choosing the forum software I did choose, years ago, was how many options it offered me that fitted my needs.
I was also seduced by the lovely modding community.
But I discovered that mods can be a pain over time because sometimes they just don't work; getting changes made as my board needs changed has been difficult or impossible - mods got too busy to help even if paid, or disappeared all together. (An honorable exception was Logician who hangs in there updating, and providing advice on adaptations way beyond the call of basic duty.)
Upgrades can be a mess for a lot of people I understand.
So the oft repeated cry "you can mod it" is not at all the ideal solution, at least not reliably.
If you're a coder you can. If you're lucky and get a good coder for love or money, you can. But many of us can't, don't have enough time or energy from our many projects to learn, and can't find reliable coding support.
So, back to the core, the integrated stuff.
It would be helpful to understand a bit more what the pressures are about this. I'm beginning to understand that it's not so simple as just adding on things so admins can choose.
People talk knowledgeably about "bloat." The concept is intuitively understandable to me, but only superficially.
I thought it would be useful for me and quite a few others to open this up and educate us more on what "bloat" is about.
Then we'd be able to be more mature clients, with a bit more judgement skill on when asking for X, Y and Z is less or more of a problem to actually do for the team.
SAMPLE QUESTIONS
These might not be the way you'd approach the subject. But they illustrate the kind of mindset of a non-coder admin.
~ What kinds of functions are the worst criminals re "bloat"?
~ What kinds of functions are reasonable re "bloat"?
~ Are there other considerations where feature X actually cuts down on a mass of stuff - shortcuts it - so if it adds in another way there can be a net gain?
Another way of putting it is
~ What kind of [Suggestions] are welcome as comfy to put in?
~ What kind of [Suggestions] are an unwelcome sight because they look simple to us non-coders but they mean headaches for the team? (or a modder)
LATER: Then there's "plugins" which seem to be a halfway house between "core" and "mod."
I just thought if we admins who are not coders could understand the developers point of view just a bit better we could be more considerate and not waste time with unworkable ideas.
Of course some of this will be unpredictable - it depends on a lot of factors - kind of thing.
But surely it should be possible to explore at least some outline guidance.
