Taking control of contrib nodes when not being maintained

Is that a good measure of an abandoned node?
Maybe it was just well written in the first place, and therefore there was no need to carry out tweaks & fixes :wink:

1 Like

I didn't suggest it as a measure, just an indicator that it might be worth a ping from the dev team to see if the author is still active.

Do you mean like node-red-contrib-random-event-generator? :slightly_smiling_face: I wouldn't mind an annual e-mail asking if I am willing to respond to issues.

1 Like

There are some really valuable thoughts in this thread.

  1. Helping maintain core nodes

    I will admit that I struggle with this. It isn't a lack of willingness to try. But I find that it is hard to clearly see what might need doing and harder still to do any work while they are munged together in a single module.

    Would a useful starting point be to create a new forum section? Where we could start to look at key issues and suggestions for these nodes?

    Also, if each node had their own list of issues, that would help. Each in its own @node-red module would also make life easier. Maybe that's the place to start?

    Maybe some of this already exists and it just needs Nick/Dave to walk us through some stuff?

    Another idea might be for a few of us to "sponsor" a core node. To agree to help support & develop it for a while?

  2. Identifying unmaintained nodes

    I think that a separate table of nodes that:

    hadn't been updated in 2 years and had dependencies that were out-of-date or had known issues with current versions of Node-RED

    would be really useful. It would help others in the community know what might need some TLC and know how to help out. As you say, by contacting the owner of the repo first.

    Nodes in that table could also be marked in the flows library but a simple list would be really useful as a quick reference.

    2b) might be quite hard to work out but 2a) should be scriptable. The whole thing would have to be run periodically by script so that it wasn't adding to resource overheads.

3 Likes

Yes agree, and having experienced this issue a number of times it's very frustrating, and by example, and most recently with node-red-contrib-ringdoorbell where I've raised an issue, but suspect that the author may not respond.
So my next step maybe to try & fix the problem and publish node-red-contrib-ringdoorbell-2 which isn't really a good solution, as well you know.
But as there is only one 'Ring doorbell' node, it maybe the only way forward.

Yes you've raised an issue, you could also offer a Pull Request to fix it. The author may be more responsive to actual offers of help. You can also try a direct email, to check if they are still interested, and then finally yes go ahead and create a new version.

If you get no luck on their issue list, then this can be a useful next step. One tip - npm owner ls <module-name> will list the owners of the module and their email addresses. Useful if a node doesn't list a git repo or other obvious way to contact the author.

If you do go that route, just keep in mind you have no idea why the user hasn't responded. It could be they have turned off github notifications for some personal reason. They may have had to move onto other things. So tread gently and be a positive representative of the NR community.

On the topic of identifying unmaintained nodes... this is certainly something I'm going to look at. If anyone is interested in collaborating, please do message me directly or on slack. I've got access to all the raw data, so as @afelix said, please don't go scraping the flow library site directly.

Tried that. No reply.

...and all the other outstanding issues? Future issues?

I gave this as an example, and don't get me wrong, there may be good reasons for this: gone out of business, prioritising workload, health, etc, etc.

I'm just reinforcing the need to generally address this as per Simon's original post, from a user perspective.

Would it be better to have NR Core members publish the npm module, so the plugin name is owned by NR and more easily transferred to a new maintainer? Maybe a plugin review step, then publish, prior to being displayed for installation. I've had to dive through 4 different AWS SDK plugins repositories, before I found one and it was unmaintained.

Not sure if this is feasible, but just throwing an idea out there.

For those interested, here is a dump of the relevant data.

For each node there is column for:

  • when it was first added
  • when it was latest updated
  • how many days since it was created (based on today's date)
  • how many days since it was last updated (based on today's date)
  • how many days was it 'active' (days from created to updated)
  • how many downloads did it get in the last month (minor caveat - any module that has refreshed today will have its downloads set to 0 because thats how it works).
  • the list of npm users associated with the node

I have added colour scales to the - days since updated, days active and monthly downloads columns.

From this we can identify nodes that warrant some further action to see if they should stay in the library. Please do not take any actions yourselves based on this data. I'm sharing this data in the spirit of openness. All of the information within it is freely available via npm.

Of course I could have scripted it, but sometimes dumping data into a spreadsheet and playing around with it is far more effective. And now I have a better sense of what processing needs to be done on the raw data, so I could automate it for next time.

No. We don't want to become the bottleneck or gatekeepers to the community. That was an intentional decision we made at the start. We do not have the resources to review every update that gets made - in a typical day there will be 10+ node updates published. That would be almost a full time job.

This is one of the reasons we added the ability to rate individual nodes in the flow library - so the community can help curate the list. (As I write this sentence, I realise I haven't included the rating score in the spreadsheet. I may go back and add that... or I may not.) So if you've tried a number of AWS related nodes and hit issues, I encourage you to rate the nodes accordingly in the library.

1 Like

Is there no way to extract data about 'issues', ie number of, and days since last issue recorded.
That maybe would help with the selection criteria.

None of that information is held by the flow library - it will be held in what ever issue tracker the node is using.

The information can be mined, but is considerable more work than the quick database dump I did this morning.

Not all nodes identify a git repo and lots of the cloned nodes haven't updated to point at their own repo vs the original node's repo (which is another indicator to note).
It will certainly be worth doing - just needs more time/effort than I can spare today.

1 Like

Following the discussion for a while I like to add a comment now

I’n my personal experience the use of star ratings are very limited. Seen from both sides as a user and a developer

  • “It is easy to criticize” as on shopping sides you will get all kind of criticism which is often not related to the product itself. Without a descriptive text you now nothing. Was the one star rating by accident, because of not reading the doc or because the node do not fit the individual purpose. (On my node i have one one star rating without any feedback no issue no discussion no nothing)
  • You get negative feedback more likely than positive. When was the last time I went back to the library and gave a 5* rating for a node that helps me a lot?

The main reason why I switched from another home automation system to Node-RED is the freedom and the possibilities out of the contrib sphere. So many great nodes so much hard work. We should think twice to give this up. A review mechanism will put up a huge barrier for innovation and fresh ideas. Even the idea to take the ownership from the beginning will take a lot of the motivation to participate.

But I agree there is a problem with none maintained nodes for beginners selecting the right contrib-node. Most of us will always take a look on comments in the forum, look into the issues and revisions and do tests before relying on a contrib-node. Issues on GitHub only by number gives a wrong impression too as many projects use the issues for discussion, feature requests and many other things. Same for any last updated dates (as mentioned before)

Here are some of my Ideas, hope they are not all duplicates:

  • establish a link between the forum and the library by listing links out of the forum where the node is mentioned. A active discussion can say a lot (used by others, feedback, experience, tips and tricks, solutions ...)
  • instead of the stars there could be a tag system were users could give a selection of tags to a node: usefull, limited usecase, incomplete, has bugs, well maintained, seems to be dead (i leave the wording to somebody else). Tags can be counted and there should be a small text box to give a reason to the developer and other users to get into contact. The developers should be able to get into contact to the commentator too - so many miss understanding lead to bad things.

So in the end it is a question of social skills to communicate and own responsibilities.

Finally I like to say that Node-RED is my favorite of many projects (not only IT related). Friendly people, always willing to help newcomers. Especially @knolleary and all the others working hard in maintaining not only the code but also the friendly atmosphere: Thank you so much.

Nick, I've started looking at the nodes from 2014 - how do you want reports? For instance:
node-red-contrib-async - a PR was merged 14 days ago, but it doesn't look like it was actually applied to the code. Should I point this out to the owner?

Then there is node-red-iced-coffeescript - the contact info references a URL that no longer exists.

Sadly this isn't just a problem for node-red-contrib packages. The problem exists for npm packages, useful javascript libs, toolkits and many open source communities.

There is an abandonware effort that we might want to learn from too.


I think that the best way to enrich the data would be to integrate the npms.io API which already has some metrics about quality.

https://api-docs.npms.io/

This would be better than tracking numbers of stars for sure.

However, it is more work as you say. Shouldn't be hard to do though once you've gone from a one-off db query to a script.

I took all the nodes not updated since 2014 and took a look at them. Here is what I found:

Nodes last updated in 2014

Owner active on GitHub - node working
-------------------------------------
node-red-contrib-mapper			owner active - no PRs no issues - works as advertised
node-red-contrib-async			commit was done in Jan 2020 but says it is 5 years since published - asking author about this
thethingbox-node-sensortag		still being downloaded - sites last faq entry references Jessie - many grammatical errors	
thethingbox-node-timestamp		node works, adds msg.timestamp to msg

Owner active on GitHub - node not working or has bug
-------------------------------------
node-red-contrib-collector		owner active - owner recognize bug but it has not been fixed since 2017
node-red-contrib-ds18b20		two PR from 2016 and 2017 waiting to be applied
node-red-contrib-logentries	 	owner active - node gets an error at startup
node-red-contrib-neo4j			owner last active March 2019 - 1 issue (2018) and PR (2017) pending

Owner missing/not active on GitHub
----------------------------------
node-red-iced-coffeescript		owner gone - owners url link no longer exists
node-red-contrib-ssdp-discover	owner gone - node still works
node-red-contrib-pitft-touch	owner last active on GitHub - August 2017
node-red-contrib-iotclouddev 	owner last active on NPM 2yrs ago
node-red-contrib-orchestrate	owner last active June 2018 - no issues or PR's
node-red-contrib-crate			owner last active June 2018 - open issue/bug since may 2018
node-red-contrib-iotclouddev 	owners last activity on NPM 2yrs ago

Odd balls
----------
node-red-contrib-rtcomm         node renamed to lib.rtcomm.node-red
node-red-contrib-jsonpath	 	owner Knowledge Media Institute - The Open University. looks like an early version of JSONata
node-red-node-babascript	 	node says it is under development

Does this help?

4 Likes

What I think is that there needs to be some sort of board of officers that reach out to the author. They can work with the author to take the best steps forward.

The board can also reach out to contributors. These work for other organizations, why not here. We know the few that are the leads here, why not acknowledge them. Maybe NPM and Node-Red both have boards that work with each other...

@dceejay @knolleary would start and ask for counsel from others to round out the board.

Then there can be 1 board discussion a month. They can ask for topics beforhand.

This sounds like overkill for the contributed node problem and just a bit contrary to the spirit of open source. Spotting the issues and appealing to contributors' sense of responsibility to the community is as far as I think we should go.

3 Likes

All things benefit from prudent oversight....

:slightly_smiling_face: Quis custodiet ipsos custodes?

2 Likes