Kanboard
Replies: 7 comments 11 replies
-
|
Due to the discontinuation of Trello, we have adopted Kanboard as our internal management tool. To avoid the common situation where suggestions are made but not shared, we plan to release our modified version of Kanboard in a new repository. This is scheduled for November. We have already made extensive customizations and believe it is sufficiently usable in its current state. As a development company, this decision might raise ethical concerns, but it is disheartening to see plugins that have been abandoned for nearly a decade or are functionally inadequate still in use. We feel that the original creators are gradually being forgotten, which is not respectful to them. Therefore, we seek the opinions of fellow developers on this matter. If the feedback is negative, we will use this project exclusively for our internal purposes. This decision stems from our deep respect for those who have led this significant project so far. Currently, no one is actively stepping up to improve Kanboard. We aim to remove the plugin concept entirely and create a standalone version of Kanboard. We hope you understand that this is an unavoidable choice.
|
Beta Was this translation helpful? Give feedback.
-
|
@YamonBot Why do you not create a new project on github? Certainly these modifications are useful for a lot of cases. |
Beta Was this translation helpful? Give feedback.
-
|
The basic features of Kanboard are very robust, and with just a few more tweaks, it has the potential to become a killer open-source tool that could completely surpass Trello. |
Beta Was this translation helpful? Give feedback.
-
Honestly, I'm not sure what you are referring to, because I don't see a single pull-request from the YamonBot user. There is nothing that prevent you to make pull-requests to Kanboard like other contributors. As mentioned in the project readme, the project is in maintenance mode, so there is no particular roadmap or direction being taken. Like most open source projects, people contribute on whatever they feel like working on. Some people develop plugins for their own specific needs, while some contributors add features directly into Kanboard. Citing the Readme:
|
Beta Was this translation helpful? Give feedback.
-
Thank you for your kind response. Although I am already aware of the rules, as you mentioned, Kanboard is currently in a maintenance state, which I think is problematic due to its lack of specific direction. Initially, I planned to submit a pull request with the modified code. However, as I mentioned, after making necessary modifications for our organization, the changes were too extensive to merge with the branch you are managing. In our opinion, allowing users to choose plugins according to their preference is very effective. However, the ability to use various features has been possible because such a design has existed over the past decade. From a developer's standpoint, Kanboard currently has a variety of features that do not need major modifications. However, many features are still missing, and elements will continue to be added. For instance, after replacing the editor with another, the @mention, react imoji feature we added caused several derivative side effects due to the plugins. Based on this experience, I believe that the functions of all plugins should be integrated into the main code, and new useful features should be added directly to the central branch. After reviewing about 70 Kanboard-compatible plugins on GitHub, most plugins depend on another plugin, but the original plugin hasn't been updated for years and is not compatible with the latest Kanboard, leaving the derivative plugins abandoned. Features like customizer or metamagik are core functionalities robust enough to depend on other plugins. Such functionalities should not be applied according to the user's preference but integrated into the main. Our proposed direction is:
We have only been onboarded to this project for a few weeks, and it seems that a reply feature has been added in the latest pull request. Due to that conflict, we have removed that feature from our code. Such conflicts will routinely occur in the future. We were in a situation of reinventing the wheel. I fully support the results you have achieved, and this direction is just our way. If the main developers do not agree, we intend to keep this direction internal to avoid disputes. |
Beta Was this translation helpful? Give feedback.
-
This does not sound serious. I don't even know where to begin. It's vague, it would not solve the issue being raised, it goes against all notions of abstraction and modularity that has formed the foundation of so much of software development for who knows how long, it removes people's power to customize Kanboard to their specific needs and use cases, and it destroys an ecosystem. This idea is so bizarre it sounds like trolling to me. Fully against it. |
Beta Was this translation helpful? Give feedback.
-
|
I also think there are issues with the current situation where Kanboard is operated through two channels: the Kanboard forum and GitHub. Originally, it was mainly managed via the Kanboard forum, but your firm decision led to additional management on GitHub. This has caused various branches to emerge, and there is a lack of developmental sharing about issues. Of course, it's because of these processes that Kanboard exists today. If someone as exceptional as Alfred from the forum participates in the source level on GitHub, it could usher in a new golden age for Kanboard. |
Beta Was this translation helpful? Give feedback.
-
|
This entire thread feels so suspicious to me. If the OP wants to fork kanboard and make their own changes, great. But the behavior in this thread sounds a bit like the pattern that led to the |
Beta Was this translation helpful? Give feedback.
-
Where's your evidence for this?
Besides the fact that this can't possibly work, it's bizarre. Modularity is good. If you already have a modular system you'd better have a good reason to remove the modularity.
Where's your evidence for this? I'm in "the community", and I've never said anything like this. It's bad form to speak for other people.
A solution to what? You haven't identified a problem. You're asserting there's a problem with plugins but you haven't supplied support for that belief.
I'm not a main developer, but I've used kanboard for over 10 years. Given your offputting behavior in this thread I am uninterested in your fork. Your post sounds like an ultimatum to me--do what we say or else!--and as far as I'm concerned you can take that elsewhere. |
Beta Was this translation helpful? Give feedback.
-
You don't know what a "new person" does when they onboard. You are saying this because it serves your agenda. If you have some plan for kanboard, good for you; you've made a fork, go have fun with it. Personally I think speaking for other people is problematic and you should stop doing that. If you want to know what new people actually do when they start using kanboard, a poll or survey is one way to go about finding out. One written with a good faith commitment to finding the truth and not one that's slanted to finding whatever it is you want to hear. I'm a user of kanboard, and I do not have the experiences you're asserting (without proof) that users have, so clearly some kind of polling is in order if one wants to know what's really going on. Anyway, that said, you didn't address the core issue, which is that converting kanboard to remove the plugin functionality and instead integrating all that code into the main development path does not solve the "problem" you're asserting exists, and at the same time introduces a whole pile of new issues, besides running opposite of what most software best practices dictate you should do most times, which is to introduce MORE modularity to a codebase. It's a non-starter of an idea from where I'm sitting, based on this. If there is a real problem behind what you're saying, it sounds to me like it's the standard problem that affects any open source software project that does not have a large base of developers maintaining it. Sure, plugins are abandoned sometimes. Sure, there are dependencies among plugins so that when one is abandoned it affects others. Sure, that's annoying. But that's not a problem with the structure of the code, it's a problem of human beings having other stuff to do besides volunteering to update open source projects. That condition doesn't change when you refactor the codebase. If you want to throw some financial backing behind plugin maintenance that might help. I wouldn't know though because nobody's been surveyed to find out what the real problem(s) are, if any. |
Beta Was this translation helpful? Give feedback.
-
|
If I got paid, I'd update my plugins more frequently. That's a true statement, that I can verify, no poll needed here. |
Beta Was this translation helpful? Give feedback.
-
|
@axb21 If we had at least adhered to the MVC pattern and chosen a single framework to start with, this problem wouldn't exist. The plugin concept is only valid when the main code is active and isolated in a complex service layer within a safe zone, but Kanboard allows tuning all its features, which leads to problems when approached with a plugin concept. PHP is already losing interest, and you have strengthened the dilemma of dependency. Who is speaking without basis on such fundamental development knowledge? I have seen many people on the forum facing problems like mine, and we are currently conducting a "survey" about it. What do you think about communism if speaking on behalf of someone is an issue? At least @creecros is a significant contributor that I can mention, and even if we follow my direction, he is essential. He does not agree with my opinion, and it seems the main administrator also disagrees with this direction. This discussion has been up for months without others participating, so we will upload a demo video next week and make a final decision by July. |
Beta Was this translation helpful? Give feedback.
-
|
I have actually paid my employees and proceeded with the development. Honestly, even if we transition to a private setting, it won't be a problem for us, as the main intent was to share and improve our work. There seem to be dozens of people with similar intentions on the forum over the past 10 years, but it looks like everyone gave up and left. It's probably because of reactions like the ones above. I also now foresee a similar conclusion for myself. |
Beta Was this translation helpful? Give feedback.
-
|
I would say I don't agree or disagree with anyone. I just like to chime in sometimes on threads to feel special. I very rarely contribute to kanboards main code, cause I don't trust myself to not screw something up. Writing plugins gives me the freedom to screw everything up until I succeed. But for me, it's like playing a video game, just a Hobbie, and like hobbies I go through phases. If kanboard was not this way though, there would be a slim chance I would have contributed what I had. |
Beta Was this translation helpful? Give feedback.
-
The chronic problem with Kanboard is that while it supports a variety of features in the form of plugins, as the main Kanboard complies with the latest HTML and JavaScript standards, plugin developers are departing, and the plugins dependent on those abandoned also get discarded routinely. I believe plugins should operate as a testing ground for users, and all functionalities of the plugins should be merged into the main code. Everyone in the community points out this issue, but no one has been able to provide a solution. Since we follow the MIT license, even if the main branch does not accept it, we will continuously make pull requests with an integrated branch of useful plugins. If this proposal is not accepted, we will fork Kanboard and create a new project in the direction we envision. I am seeking the opinions of the main developers.
Beta Was this translation helpful? Give feedback.
All reactions