consider merging projects

What is the difference between your project and c_notify?

Comment subscribe basically allows users to subscribe to comments whereas comment_notify allows users to subscribe to nodes. This is functionally different and structurally different. Internally the module tracks the tree structure of the comments so as to send notifications to only those users who have subscribed for the comments for which the new comment is a child of, whereas comment_notify just uses the subscribe flag for the comment to send mails to all subscribed users of a node for each new comment.

comment_notify sends email notifications to those users (anonymous or registered) who have commented on a given node about any comment posted on that node. This does not serve the purpose when comments are mostly questions or requests for help. A person asking a question on a node does not have to get a notification when another person asks another question.

One the other hand comment_subscribe allows the user(anonymous or registered) to subscribe to their own comments on a node. The notifications will be sent only when somebody replies to his/her comment or child-comments. So a person asking a question will be getting notifications only about answers to his question.

The number of notifications sent out in comment_subscribe will be far lower than those sent out in comment_notify. In addition the notifications are more relevant to the end user. Since the notifications are relevant, the rate of unsubscriptions would be lower and the number of repeat customers who are satisfied would be larger. This should help increase traffic to the site. We have been successfully using this module on our site - zyxware.com and has seen significant increase in our traffic.

greggles thanks for getting this message out so i could find it using search. thanks to the module creators too. here are a few thoughts...

1. perhaps the comment_notify might be recast as node_notify (might create havoc, but really no more than when a module is deprecated for another).

2. either project might add the other module's features (not the drupal way methinks).

3. the modules could both deprecate and merge to become node_comment_notify or node_activity_notify (seems more fair to both module authors/teams).

4. or easiest of all the check box text messages might be slightly clarified in both projects...and best of all made more parallel in use of terms...

"Email me about replies to this comment." (comment_subscribe module) might become...
"Email me about replies to this specific comment." or for parallelism...
"Notify me of replies to this specific comment."

"Notify me of follow-up comments posted here." (comment_notify module) might become...
"Notify me of all follow-up comments posted to this node. (or better yet, let the admin put in a string to use for this, like article, blog entry, &c.) or for parallelism...
"Email me about all replies to this node."

5. since one perhaps seems more formal and the other less so, and language on a site is best when able to reflect the tone of the site, perhaps both modules (or a merged one) could allow the admin to customize the check box prompt message (without hacking the node, which is easy enough of course until update time and doesn't seem to be the drupal way).

thanks and skateylove...roadskater.net

Replying to myself here (not that unusual for me, ha).

I note that the two modules share a LOT of code. For example, it seems that if you use both modules, you'll get the same notification twice in certain circumstances, the message being...

"ATTENTION: your comment is NOT YET posted - please click the post button to confirm your post"

The stated owner of the modules is not the same, so I'm assuming that one is largely borrowed and modified to specific needs. But this shared code seems like a good reason to work for a merger, too.

I failed to notice earlier that in the code for comment_subscribe there appears to be a choice (made by the admin) to EITHER offer notification of node changes or comment changes. This choice made by the admin means the user does not get to make this choice using just the one module. I also see some code about notification of changes to the original article, if I understand correctly. This brings me to things I would like...the code seems to be there for the most part already in comment_subscribe:

* Instead of having the admin choose whether to offer notification of all replies to the node or notification of replies to the specific comment, I'd like to see 3 checkboxes at the bottom of each comment form (and the second as the only choice for a node writing form):
* Email me when changes are made to the original article.
* Email me when any comment is made in reply to the original article.
* Email me when any comment is made in reply to this specific comment.
* Of course the user should not get duplicate notifications,
* On my site, anons can't post, but I would like to allow anons and regs to sign up for email notifications on any article or comment, not just ones to which they have contributed. Perhaps there is already a module for that, and I have not looked yet. (I use Notify module as well to get email summaries of content over several days at a time.)

Also, perhaps, I'm not making sense at all. Thanks and skateylove, roadskater.net

I just downloaded both of these modules and have tried them on my site. I wasn't sure what was going on with these two extremely similar modules (the default notification email even has the nearly identical text), but I thought maybe I'd found a bug or two in comment_subscribe so I hit the queue and my browsing through landed me here.

So, as someone who just stumbled on to this, I think have found three differences between the modules:

• comment_notify lets you pick the node-types for which following is allowed, comment subscribe does not
• comment_subscribe lets you pick whether to follow comments for the whole node or just a comment-tree, comment_notify just follows nodes
• comment_notify allows permission control on who sees the checkboxes, comment_subscribe gives it to everyone

I noticed that neither module seems aware of the "Anonymous commenting: Anonymous posters may not enter their contact information" setting (comment_notify does at least have permission control to avoid the incongruous checkbox), but I'm not sure whether to pass that on to either or both maintainers. Should I feature request and bug-request both and see who gets to things first? :-) It seems wasteful of time (and maybe tacky).

So, in short ... new user ... confused.

Can't the one missing feature from comment_subscribe be moved to comment_notify? Or the two from comment_notify be moved to comment_subscribe? Ideally, there'd be one module which would let admins put "node subscribe", "comment subscribe", neither (if the role can't include emails), or both, on a node-by-node and/or user-by-user basis. I do not think, as was explained earlier, that these two modules occupy different niches; rather we have two modules with not-quite-perfect feature overlap.

So, that's my two bits.

Please check out #320062: Module Maintenance Status thread to see the continuation of this conversation

I posted this in #320062: Module Maintenance Status, and I wanted to re-post it here as well.

My reasons why comment_subscribe should be merged back into comment_notify:
1. comment_notify was the first project. It started in December 27, 2006 while comment_subscribe started on February 20, 2008.
2. Since your module [comment_subscribe] was created later and started the majority of it's code based on comment_notify, you probably could have easily filed a feature request patch against comment_notify for your different method of subscribing to comments. I did a search through every single comment_notify issue, and unless you used a different Drupal.org username, you did not participate or submit any issues. You just went and created your module anyway, which is not the recommended way to help contribute back if there is a very similar, existing module.
3. If the module was not being properly maintained, you could have applied to take over as a maintainer as per the policies specified in the "Dealing with abandoned modules" handbook page instead of starting a very similar module.
4. Currently, comment_subscribe has 700 6.x and 161 5.x reported users while comment_notify has 964 6.x and 379 5.x reported users. Is it going to be easier to move 861 users or 1,343 users to a different module? All signs would point towards the former. It's fairly easy to move users to a different module. You'd have to work together with the greggles to create one update function inside in comment_notify_install() that would upgrade users/data from comment_subscribe. Then basically turn off all releases on your project page, turn off the issue queues, and make a nice big link on the project page saying the modules have been merged. I had to do this for one of my own modules.

A final decision has been taken considering that this is going to be in the best interest of Drupal and the community. We are planning to merge the modules comment_subscribe and comment_notify and we have discussed this with greggles. Keeping the interest of all existing users in mind, we will be providing a clean migration pathway for this module.

The migration plan is going to be as follows.

a) Implement support for multi-level nested comments in comment notify.
b) Create an update in comment subscribe that will migrate all existing data to comment notify.

Until migration plan is implemented we will keep supporting existing users of comment_subscribe. Once we implement the above items, the existing users of comment_subscribe should be able to easily migrate to comment_notify easily and we will continue our support through comment_notify module.