View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0023842 | mantisbt | plug-ins | public | 2018-01-16 16:03 | 2018-02-18 18:05 |
Reporter | Starbuck | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | acknowledged | Resolution | open | ||
Product Version | 2.10.0 | ||||
Summary | 0023842: Initiative to significantly enhance event signaling | ||||
Description | This is a suggestion that at every opportunity, when making core changes, to consider if the function they are working in is a good candidate for a new event. The code is about to do something - fire an event. The code just did something - fire an event. The core is making a decision about doing something - fire an event. Something is going to get displayed in the UI - fire an event. I suggest, developers adopt a common standard to simply comment the code where an event may be of value. Examples:
With this policy in place, we'll get a lot of these comments in the code. We can look through the code, and pick targets for implementation. At that time, a business case can be defined in a new ticket, a specific event type and implementation described, and individuals can implement each specific feature. From there, the goal is to enrich the pool of options for plugin developers to encourage and facilitate new plugins, and to reduce the number of requests for assistance, and the amount of frustration that seems to be in the forum. | ||||
Additional Information | Every day we see a forum request for "can I do something?" or "can 'this' be added to the core?". My first reaction is "sure, that can easily be done with a plugin", but only if the core uses event_signal in strategic place to support the functionality. Despite a rich plugin system, where functionality can be implemented outside of core development, what we're seeing is that most forum requests have a resolution like "it's not in the core so we'll have to wait for it or it'll never happen". There is no DIY spirit fostered here. I think this causes people to simply walk away from the platform to use common alternatives. I'm not saying they'll find desired features elsewhere. I'm saying they migrate to tracker projects that look like they have a larger development team and more of a possibility for their desired features to be implemented. All this ticket intends to do is to establish a recognized policy, a guideline for core devs/contributors to follow. Someone like me can also go through the code and submit a PR with nothing but I'd like to see an explosion of plugins for this platform, but it must start with a LOT more event signals from the core than we have now. | ||||
Tags | No tags attached. | ||||
I'm OK with the principle of adding more events to the system, but I'd rather have plugin developers who need a specific behavior follow the usual process of opening issues in this tracker to request it, providing all necessary supporting information (e.g. use case, plugin code sample, etc) Sending a pull request with an "ADD EVENT" comment is not the right approach IMO. I don't think that the Code is the right place to track feature requests. |
|
+1 to 0023842:0058886 Adding comments to the code what could be done does not help that much. Lets go on using the usual process. |
|
With extensibility we need to be scenario driven. Sprinkling events across the code won't help for the following reasons:
I think we should focus on events that are commonly requested (rather than long tail) and ones that make sense to extend the product for. For long tail, the developers can always maintain a fork with some customization. We should however identify key areas where extensibility makes sense and make them great. For example, adding a plugin for custom authentication, plugin for a custom field type, plugin for source control provider, plugin for reports, etc. Making progress in areas like these would be bound by demand and contributors. I can tell you for sure that extensibility for auth for example wouldn't have came out of the approach suggested in this issue. It needs a lot of thinking, design and refactoring that is informed by a well defined goal. |
|
@vboctor nailed it here:
That's all I'm asking. I'm not fond of the The ultimate problem that I've been trying to take on here, my FOSS contribution, is the unusually small audience for this fine and mature software. Reasons I've heard for that include a lack of features found elsewhere and a small number of plugins. People measure the value of software by factors including the number of plugins. Mantis has no real third-party plugin community to speak of. There are many plugins, but most of them are dead or dying. That doesn't reflect well on the core. My approach to try to solve that problem includes (the forum) bringing developers to the platform, and (this ticket) making the platform more approachable by those developers. I think we're facing a chicken-and-egg scenario : We don't see so many plugins for Mantis (in part, not only, and I believe), because there aren't enough key places to hook the core ... And then of course you don't want to hook the core until you have some reason to do it. The plugin concept exists to allow non-core developers to add functionality that core developers either didn't imagine or didn't have time to implement. I believe the answer we should see in forums is not "no, that can't be done" but "the core doesn't support it, but there is or can be a hook that will allow a developer to create a plugin to provide that functionality". This is a mindset, a worldview, that software can do anything a user wants if the user is motivated enough to make it happen. People are still thinking of software in terms of the cathedral rather than the bazaar: If they are told that their FOSS doesn't do something, they are more inclined to drop it entirely in favor of something else, or simply do without. The world is full of examples where a core developer slows down and end-users abandon the software. They leave like locusts moving from one package to the next, with hardly a thought about motivating someone else to maintain it. What they should be doing is to recognize and support the idea that their software is extensible and that anyone can maintain their FOSS. But that needs to be combined with a recognition that they can't ask core developers to provide every possible feature. So to get developers to create more plugins, I believe the software needs to be more accessible for a variety of add-on functionality. I don't care how that happens. But I'd like to help move that forward in a way that is the least painful for this team. Now that you have my perspective of this, I'm hoping we can refine this ticket. Reject the original proposal for how to solve a problem. Simply acknowledge the concept. And ideally, if there is agreement, to follow with alternate proposals. Thank you VERY much. |
|