Collaborate with Radioactivity

Well, that was fast.

I know it's better to contribute to existing projects and that overlapping functionality among contrib modules is considered unwelcome by many people and all that. I knew what I was doing by publishing this project. That said, Scoville came about because I needed Radioactivity-like functionality on a client's site, but simply couldn't get Radioactivity to work. As it is, Radioactivity has two huge problems: One, its initial configuration is extremely complex; two, its documentation (as linked to by the "Read documentation" link in the project page sidebar or searching the D.o site) is out of date and mostly irrelevant to the Drupal 7 version. (There is a blog post linked to from the top of the project page which has a bit of D7-relevant info, if you notice it (I didn't at first), but it's still incomplete.) The first problem wouldn't be so much of a problem if the second problem were not as great a problem as it is.

So there are two ways that I could improve Radioactivity. First, I could go into the issue queue and say, "Hey, this complex new configuration method you've built for the D7 version? Let's throw it all out and start over with something simpler." Yeah, somehow I doubt that would go over well.

Or, secondly, I could improve the documentation. But in order for me to do that, I'd have to know how to configure Radioactivity myself, and after spending hours pouring over the code - sometimes at the level of stepping through parts of it with a debugger - I still failed to figure it all out. I thought I got close once, but sometimes a node's score would go up, and sometimes not, and I couldn't figure out why. It's always frustrating when code stumps me and makes me feel stupid, but that's what happened here. (That being said, I did create an issue queue thread suggesting they update the documentation. To the credit of the Radioactivity dev(s), the issue was responded to quickly and bumped up to critical status, but the reply was basically "yeah, we should get around to that at some point," and nothing has moved forward with it since.)

Thus, I am unable to contribute to Radioactivity towards the goal of making it simpler and/or easier to understand in any useful and practical way at this point. Meanwhile, our client still needs this functionality on their site. I could either fart around with Radioactivity more, hoping that at some point I figure out the secret incantations to get it to work as expected, or I could create my own solution, document it well, and throw it out there with the hope that other frustrated site builders will also get some use out of it. With my employers' blessing, that's what I did.

The goal of Scoville will always be to achieve this "hotness" functionality as simply as possible. It will be the iOS to Radioactivity's FreeBSD. And perhaps if Radioactivity some day greatly simplifies its setup procedure and/or greatly improves its documentation, Scoville will become redundant. But as it stands, I think there's a hole in the contrib space for a simple, well-documented way to create a list of hot content, and Scoville helps fill that hole.

It is definitely not a duplicate. It is a much lighter module for people who don't need complexity in counting a node popularity.

Normally, I believe that modules that accomplish the same task should be avoided. But when the UX is dramatically different, I believe that can be a justifiable reason for an alternative implementation.

It's worth noting that up until this point everyone aside from myself who has commented on this thread works for the same company.

Yeah, we're kind of ganging up on you, sorry. I posted a link to this issue in a company chat channel, and though I didn't explicitly ask anyone else to comment, some have chosen to do so anyway.

It seems like you acknowledge that improving the ease of configuration on Radioactivity is feasible and that the maintainers are responsive, but a path that you chose not to take.

You're right in that I didn't attempt to find a way to improve Radioactivity to make it easier to configure, no. As I stated above, I knew that if I went into the issue queue and told the devs that I intended to throw out their complicated configuration method (which I'm earnestly sure there are legitimately good reasons for) and replace it with something more simplistic, I would be dismissed at best and ignored at worst, so I didn't bother.

It's worth noting that up until this point everyone aside from myself who has commented on this thread works for the same company.

Sure, as CEO, I'm biased, but you're suggesting that this coincidence somehow is relevant. I don't see it. As Garrett noted, a few of us have sounded off here because he shared the link in chat. I had no intention to comment, but then saw the above remark and felt the need to respond. As a company, PINGV has been a good Drupal citizen, has contributed modules and themes, and has lent a shoulder to many existing projects, including Drupal 7 upgrades of several modules, not the least of which being Salesforce. We work issue queues more than most shops out there. As individuals, each of the posters here in this issue has a strong track record of contributing.

In this case, we at PINGV had a choice:

1. Try to understand, debug, rework, propose, discuss, patch, and wait for Radioactivity changes, with inherent added costs, time investment, delays, and uncertainty, all for a module that provides major overkill over the client's needs.
2. Code up a simpler approach to do what we need.

Due to the exigencies of the project, we opted for #2. Then the choice was whether to contribute what we worked up, and that seemed to be a no-brainer, as it may prove useful to others.

So perhaps this is a documentation issue, because Garrett's explanation that "there is a hole in the contrib space for a simple, well-documented way to create a list of hot content, and Scoville helps fill that hole" did not come through in the project description and documentation page.

I'm new to Drupal and I don't work for the company, so I thought I would add my thoughts on the matter. My thoughts were that you didn't have to change the configuration, but add a toggle to enable a simpler config, but seeing that you had trouble grokking the code, I think that you made the right choice. If a good drupal citizen has trouble with it, then certainly a new user would.

I want to thank you all for the work that you've contributed, and also for deciding to release it. Choice is good.

Correct me if I'm wrong, but it seems that they went by the book on this.

http://drupal.org/node/45111:

Support requests should never be marked 'critical' or 'major'

Had to offer my $0.02 on the matter. Generally agreeing with Topcheese:

As someone researching entity popularity modules (and currently leaning hard towards Radioactivity), I have to say that it seems like Scoville fills a need alongside Radioactivity in the same way that Aggregator fills a need alongside Feeds. They appear to satisfy similar but distinct use cases, and if Radioactivity does not or cannot satisfy both (eg: "simple mode"), then the Drupal community had an unmet need that Scoville addressed.

A private organization developed a custom module to meet that need and contributed the code back to the community, which seems laudable.

Personally I think I'd rather see a "simple mode" on Radioactivity, but until that exists, Scoville has its place in my list of options.

And many thanks to the developers of both projects!

As an aside, the only reason I am leaning towards Radioactivity is because Scoville relies on the core Statistics module, which has performance implications for my site. Otherwise I would be testing Scoville on the site right now.

EDIT: After going through the setup process for Radioactivity, and following the procedures linked to from its project page, I found the current version of the Radioactivity project is pretty straightforward to install and configure. That concern appears to have been addressed.

@jweirather really? I've been trying to set up Radioactivity on three different sites and still don't have it working on any of them. I've also been digging through the code and throwing out debug statements all over, but my page views are still never counted. I've read the documentation and blog posts, and I've determined that the view-counter in Radioactivity just plain doesn't work. I'm working on building a new view, but it has been very painful due to the complexity of that module.

I was super excited when I found Scoville, until I learned that it also relied on the core statistics module (which I also can't use for performance reasons). But even though I'm not going to use this module myself, I do feel @Garrett Albright's pain, and have been considering doing the same thing to radioactivity myself. My goal would be to create a module that works and hopefully also be simpler to understand so other people might have a shot at also contributing to it as well.

Here are the options as I see them, in order of preference:

1. Fixing radioactivity (this assumes active maintainers over there, and that I know how to do it) NO and NO
2. Forking radioactivity and removing all the crazy (this assumes I know how to do this!) NO
3. Porting the (working) Drupal 6 version of radioactivity to Drupal 7 (I'm leaning this way)
4. Starting over from scratch (what @Garrett Albright did)

In general, I like the idea of collaborating and solving a problem with one module rather than creating a duplicate. However, when a project get's so complex that the people generally capable of working on it - can't anymore, then that's a good reason to try something different. ;)

@jenlampton: Yeah, Radioactivity is working perfectly for us. It's been many months, but **if I recall correctly**, once I made it past a few initial setup issues it all made perfect sense. In particular, following these instructions, getting the radioactivity-bootstrap.cfg.inc settings in place (/admin/structure/radioactivity/settings), and getting the individual radioactivity field formatters to display emitters, eg: radioactivity field settings at node/manage display. I don't remember exactly what the "ah-ha" moment was, but something clicked and then everything worked. [sorry for thread hijack]

A couple of other notes:

1) another module we needed required the statistics module (and better_statistics), and we haven't noticed a performance hit yet. As a result, I'm not sure how much the statistics' performance issues persist with modern hardware/caching/db configs. As a result, Scoville is now back on our radar for future implementations.

2) I'd also thought of just using points and rules to create a basic popularity system, but the "decay" process seemed elusive. There would have to be some cron process something or other.

Feel free to contact me directly if I can be of further help.

Some people like Radioactivity and some Scoville. Let's not necropost and claim hey are duplicates, then.

@alexrayu: I apologize for having commented on an old thread, but I think it's noteworthy that this thread is 1) still marked as active, and 2) still drawing constructive community discussion. I ask in all sincerity: if that conversation doesn't belong here, then where should it go?

Perhaps a new Scoville thread or doc page comparing it to other modules/options, allowing for discussion in the comments? And maybe close this thread and refer to that page?

Or just a title change?

It's not my thread and I'm not sure about the netiquette here, so please let me know what's best. I'll be happy to take care of the rest.

@jweirather I did not mean to suggest that there is a problem, please excuse me if I sounded like that.

@alexrayu: not at all, I understand completely, and you have a point.