View Issue Details

IDProjectCategoryView StatusLast Update
0023842mantisbtplug-inspublic2018-02-18 18:05
ReporterStarbuck Assigned To 
Status acknowledgedResolutionopen 
Product Version2.10.0 
Summary0023842: Initiative to significantly enhance event signaling

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:

//ADD EVENT:  Give plugin the opportunity to suppress the following output
//ADDEVENT: Plugin might want to change value here
// ADD EVENT... good place to trigger a notification
//ADD EVENT - plugins could replace this logic

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 //ADDEVENT comments for core devs to evaluate. Given how simple it is (with proper considerations) to add event_signal and related statements, we should see a number of these added quickly with tickets added afterward to support their existence. Someone might just want to add a signal so that they can hook it. Or the response to a forum request might just be a new signal, and a tip to someone who wants a feature that "yes, anyone can now do this with a plugin".

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.

TagsNo tags attached.




2018-02-15 16:30

developer   ~0058886

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.



2018-02-15 17:18

developer   ~0058890

+1 to 0023842:0058886

Adding comments to the code what could be done does not help that much.
It's just another way to enlarge the existing Mantis wish list of > 2300 open issues.

Lets go on using the usual process.



2018-02-17 00:55

manager   ~0058910

With extensibility we need to be scenario driven. Sprinkling events across the code won't help for the following reasons:

  1. Without an end-to-end scenario it is hard to define the exact place to trigger the event, what arguments should go to it, what actions it can take, etc.
  2. Having too many events would make it harder to understand and leverage such events correctly.
  3. The bigger the extensibility surface area the harder it is to change the core without breaking some of the assumptions that these events will depend on.
  4. These events may not work as expected, since they are not tested by real scenarios, or may be missing from some code paths (e.g. API vs. web UI)

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.



2018-02-18 18:05

reporter   ~0058931

@vboctor nailed it here:

We should however identify key areas where extensibility makes sense.

That's all I'm asking. I'm not fond of the ADDEVENTS mechanism either. That was just a proposal as a means to an end. No one wants cluttered code or runaway options that no one will use. For this ticket I'm just proposing a recognition that developers should make notes of those key areas whenever they happen to think about it.

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.

Issue History

Date Modified Username Field Change
2018-01-16 16:03 Starbuck New Issue
2018-02-15 16:30 dregad Note Added: 0058886
2018-02-15 16:30 dregad Status new => acknowledged
2018-02-15 17:18 atrol Note Added: 0058890
2018-02-17 00:55 vboctor Note Added: 0058910
2018-02-18 18:05 Starbuck Note Added: 0058931