Kunena 7.0.4 Released
The Kunena team has announce the arrival of Kunena 7.0.4 [K 7.0.4] in stable which is now available for download as a native Joomla extension for J! 5.4.x/6.0.x. This version addresses most of the issues that were discovered in K 6.2 / K 6.3 / K 6.4 and issues discovered during the last development stages of K 7.0
Topics contains old discussions (generally more than one year ago or based on circumstances that subsequently changed) or topics resolved in other ways. Topics moved into this category are closed from further discussion.
Question Do we need a "hacks category" for Kunena any more?
15 years 6 months ago #63649
by sozzled
Blue Eagle vs. Crypsis reference guide
Read my blog and
Do we need a "hacks category" for Kunena any more? was created by sozzled
In another discussion, the question was raised about creating a "hacks" category (for K 1.6).
The reason there has not been a hacks category for K 1.6 is because there has not been a stable version that people could hack. Because K 1.6 has been in development and the code has been constantly changing, it was totally impractical to have a hacks category.
But I've often questioned the usefulness of having such a category at all. When you consider that Kunena is an open source product - the source code can be modified in any way that people might like to change it - people are free to do with it whatever they like. If people want to share what they've done then this is a good reason to have a "hacks, tips and tricks" category ... otherwise who cares?
Kunena is, above all else, a community-driven project. The main reason for having a "hacks" category is for the users to share what they've discovered. Hacks are unsupported, experimental, not subjected to rigorous testing and there are no guarantees they they ever work. The project team has enough work making sure that the product works the way that it was intended to work without the added workload in helping users experiment in changing the product, hacking it to pieces or turning it into something that no longer even resembles Kunena.
So, while we definitely encourage users to share their ideas, their hacks, with the rest of the community, I don't necessarily think that it's entirely fair that the work of answering user requests to change the product should fall entirely on the shoulders of the project team, either. The project team are already fully occupied in eliminating errors, defects in the current version or are just as busy developing the next version of the product.
As long as people understand that these are only my personal views - what I have written is not necessarily the view of the project team nor of other developers who may have an entirely different view to me - what do you think?
The reason there has not been a hacks category for K 1.6 is because there has not been a stable version that people could hack. Because K 1.6 has been in development and the code has been constantly changing, it was totally impractical to have a hacks category.
But I've often questioned the usefulness of having such a category at all. When you consider that Kunena is an open source product - the source code can be modified in any way that people might like to change it - people are free to do with it whatever they like. If people want to share what they've done then this is a good reason to have a "hacks, tips and tricks" category ... otherwise who cares?
Kunena is, above all else, a community-driven project. The main reason for having a "hacks" category is for the users to share what they've discovered. Hacks are unsupported, experimental, not subjected to rigorous testing and there are no guarantees they they ever work. The project team has enough work making sure that the product works the way that it was intended to work without the added workload in helping users experiment in changing the product, hacking it to pieces or turning it into something that no longer even resembles Kunena.
So, while we definitely encourage users to share their ideas, their hacks, with the rest of the community, I don't necessarily think that it's entirely fair that the work of answering user requests to change the product should fall entirely on the shoulders of the project team, either. The project team are already fully occupied in eliminating errors, defects in the current version or are just as busy developing the next version of the product.
As long as people understand that these are only my personal views - what I have written is not necessarily the view of the project team nor of other developers who may have an entirely different view to me - what do you think?
Blue Eagle vs. Crypsis reference guide
Read my blog and
Please Log in or Create an account to join the conversation.
Time to create page: 0.233 seconds