i'm getting more and more issues submitted indicating that other people are actually using the project.module on their own sites (i know, surprising, huh?). ;)

i'd love to have a way to communicate with these people in a more structured way than leaving comments on the project node or in the issue queue. for example, the new release system completely drops support for the old "scan this directory for new releases" stuff, but i have no idea if anyone is really using/depending on that functionality in the wild. i'd love to be able to send out an email to all these people (opt-in, of course) and say "hey, i'm planning to do X, will that ruin your site?". similarly, such a community of users is an essential element in fostering a wider team of active users, testers, and eventually developers/translators/contributors for project.module.

of course, nothing i just said is specific to project.module. anyone trying to be a responsible maintainer would probably want something like this. and i'm guessing users of modules would often be thrilled to have a list of this sort.

there's the whole issue of project-specific forum posts. while that would certainly help keep the forums more useful, i don't think that's a solution to this problem, since i don't believe end users of any given module are going to be closely following those forums in the same way.

i see a few possible solutions:

  1. define a new type of group on http://groups.drupal.org called something like "Module users", and open the floodgates to creating and advertising the existence of these groups. g.d.o already provides all the functionality you could possibly want for this: email, RSS, web comments, moderation, etc, etc. plus, it requires almost no work. the only possible downside is a potentially large number of new groups (not sure that's even a downside, really).
  2. create a slew of new mailing lists. that seems like it'd be harder to maintain and would be a bigger strain on our already stretched infrastructure team. plus, you'd be stuck with a mailing list, not any of the other cooler, drupal-ish forms of communication.
  3. we could add some kind of crazy newsletter-like functionality directly into project.module itself, so in addition to subscribing to issue queues, you could subscribe to that module's newsletter. this wouldn't be a full blown list, and only project maintainers could post to it (replies being sent to the author, not the list, etc). i'm even less thrilled about this option.

does anyone else think this is a useful idea?
would people use it?
any other alternative solutions?

thanks!
-derek

Comments

ChrisKennedy’s picture

This functionality would be very useful, but my main question is to what extent does this need to be specifically integrated into project.module?

As you say, we can already create a group on g.d.o. and the "working group" type seems like it could be used for this purpose. It is easy for the module owner to then include a link to that group in the project description or as the project homepage. So my initial thought is that g.d.o. should be used for this purpose rather than re-implementing it in project.module.

dww’s picture

right. that's my point: if we use g.d.o (option #1), there's no work that has to be done in project.module at all. sorry if my post was confusing, i'm talking about users of project.module, which is the topic that got me thinking about this whole thing, not necessarily the code of project.module (except in option #3, which i don't really like, but figured i'd include it for completeness).

that said, i don't think "working group" is the appropriate group classification, since those are a) more general than specific modules (often used to coordinate efforts across many modules) and b) that implies people who are working on the modules, which isn't what i have in mind. i just mean a place for users of the modules to get/share info, and for the maintainers to announce plans, solicit feedback/reviews, etc.

something like "Module User Group" (MUG)...

___________________
3281d Consulting

merlinofchaos’s picture

I would say that this is a great option, but project should include a field (currently it's the hardcoded 'support forum thing') where module maintainers could link the project group. This makes it easy to find.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

Michelle’s picture

Why not make a generic URL field for this in project? Let the maintainers set up an info list wherever they want whether that be g.d.o or their own site. Just label it something like "To receive informational updates on this module, go to: ..."

Michelle

--------------------------------------
My site: http://shellmultimedia.com

KarenS’s picture

I love this idea. I have already had many times I wished there was a way to communicate some bit of information to everyone using a particular module and the only thing I could up with was to create a bogus issue to announce my message (I post things on the project home page, too, but I figure that practically no one goes back to the project home page once they have downloaded the module).

Not sure which is the best option above, but it occurs to me that it's nice to have something that doesn't limit communication to the module maintainer. For instance, one user may want to communicate something to everyone else using that module (assuming there is a way to keep that from being abused and turned into spam).

Anyway, as I think through it, it seems like the groups idea has the most potential for the many to many communication that might be the most useful.

mac_perlinski’s picture

Well we have developed Google Ajax Search module and i was thinking about different approach, I dont know if you had possibility to use whm, its web host manager based on web front-end. They have a nice feature so people are spread around the world but when they want to notify customers they have a message just after you logged in. So maybe we should think about new/separate module apart from project.module, googleajaxsearch.module etc.
to communicate with maintainers, if someone has the administrative rights we can show him additional item in the menu see latest notes, comments whatever, and maintainer will go there and see lates topics about all modules he has installed, and can directly email current maintainer... thats just the draft of idea. I was thinking about embedding the contact form inside the setting subpage for google ajax search module but i found it far inappropriate for the moment because that kind of action needs longer discussion and infrastructure behind it.

Well as i have read todo for drupal 5 there supposed to be web based module installer so maybe thats the place for the new tab to check latest news, polls maybe [for the moment we are using poll on our dev site so users can vote what they think about new feature].

--
kindest regards
Maciej Perlinski
http://www.meant4.com
maciej.perlinski@meant4.com

greggles’s picture

I like solution 0 (project-specific forum posts) or solution 1.

--
Knaddison Family | mmm Beta Burritos

yched’s picture

Great idea. This would be a really good thing, and g.d.o definitely seems the way to go.

Only thing is - I don't know if g.d.o curently gets much attention. From community-involved users, yes, it does (I think...), but from the wider group of "module users" that is targeted here ?

I guess we'd have to find a way to advertise the "module groups" - a link on the project page, of course, but that might not be sufficient.
- A sticky post on d.o front page ?
- A link in a flashy "this_module's user group" sidebar block on all pages pertaining to a given module (issues, issues list, er, what else ?) ?
- A notice "Did you check the module's user group" on top of forum and issue submission forms (which most people probably don't read anyway) ?
- A big note on http://drupal.org/project download pages ?
- ... ?

dww’s picture

yeah, those are all good ideas about how to publicize these groups. i was certainly not expecting end users to find these groups on their own... ;)

___________________
3281d Consulting

moshe weitzman’s picture

i would like to see a checkbox on issue creation that lets a project admin choose to broadcast to all his subscribers. would be used for security announcements and all sorts of stuff. yes, it would require a bit of new code to store such a subscription, and send the emails.

i too don't think we should make a real mailman mailing list for this. drupal should have cron based email sending and i think we shouldn't code around that.

i'm happy enough to make a MUG classificcation at g.d.o. we already have a few of them there already.

dww’s picture

i just re-familiarized myself with the 4.7.x version of OG, and realized a feature i thought existed isn't there. :( there doesn't appear to be a way to specify on a per-group basis if posts should be moderated or not. basically, i'd imagine most of these module user groups to be "moderated" groups, not in terms of subscriptions, but in terms of posting. so, all posts to this group would go into a moderation queue for approval before they show up as published in the group (and therefore, sent out to group subscribers via email, etc). this would help aleviate concerns about spam, folks not wanting to join user groups where any of the 10,000 other users of views.module or image.module might ask stupid questions, etc...

maybe there's some sneaky way to accomplish this with actions.module and workflow.module (dunno if moshe has any intention of running either on g.d.o, either). moshe: any thoughts on this sort of thing? is it already in the works (e.g. in the 5.x version?) or would this require breaking new ground? i'd consider working on this part if no one else can/will...

thanks,
-derek

___________________
3281d Consulting

greggles’s picture

I think that with a slightly different workflow you can get where you want to go:

For every day chit-chat use regular posts and people can subscribe to emails or not.

For "big things" you can send an email to all members of the group. It's not ideal, but if the module maintainer says "I'll mail you for all security and changes that affection functionality" or whatever their rule is then it works out OK.

eh?

--
Knaddison Family | mmm Beta Burritos

coreb’s picture

I'll post what I sent to the development mailing list before I read through that you wanted the comment here... sorry.

With the addition of the .info files for modules, maybe add another field to it for a news/announcement feed. It could then add to the admin pages a special aggregator page for each modules news/announcement feeds. That way, authors could get information straight out to module users, on their own site where the user actually is.

I know alot of overhead would be involved, like:

  • Ensuring module authors don't make the feed their personal blog and cat pictures end up on the special admin news page.
  • Getting module authors setup with a way to do this, either through a new blog or an add-on to the project module (suite) to have releases from cvs put into a special feed.
  • Plenty of other implications I'm not thinking of.

It's just a thought. I seem to remember some other CMS project doing this (I can't remember which one), and it seems like a good idea to borrow and extend.

coreb’s picture

Another posting made to the devel-list that I'll carry over. I will quit posting in that thread on the devel-list, I promise.

After thinking a bit more about it, this idea could supplement some sort of mailing list. I had a scenario come up that would still not allow me to see it:

One of the sites I created has it's own hosting instance just for the site. It is for an amateur photographer that prefers not to have all of the admin information clutter up her view. This site has modules that I don't use on other sites. So the special module page wouldn't be seen. I only login to her site when she has a problem or when I upgrade a module for all the sites I maintain. (Don't scold me for not setting up multi-site instances, I plan on migrating her and my other client to multi-sites when their next hosting bill will be due.)

Another idea would be very similar to the special groups.drupal.org idea is to add to the normal drupal.org user profiles the options of saying "I am a user of xx module", then automagically add them to something like a simplenews newsletter for it. An add-on module for project module could be to create (and let the project maintainer control) a simplenews newsletter. Although it may create too much clutter.

I use simplenews module only as an example since I'm familiar with it. Substitute it for the most update, capable module. I know that newsletter-like modules are in abundance, at least for the previous drupal versions.

EDIT: Second idea looks alot like what Moshe already said in the "broadcaster" comment above.

dww’s picture

first, thanks for the input. lots of interesting ideas. though, some of them have already been proposed/discussed in other places. e.g.:

have releases from cvs put into a special feed.

see features #2 and #3 from from http://drupal.org/node/77562 under "Additionally..." (near the bottom of the original post, not in the comments).

while that's certainly a good idea, and something i'd love to see us provide, i originally invisioned that stuff more like the security announcement newsletter: opt in, but you'd be a total idiot not to opt in, and you know exactly what you're getting: *just* a new item in your feed when a new release node for the project you care about is created. and, potentially this feed (or some kind of XML-RPC interface) would be used for the various proposals for semi-automated site updating tools (e.g. admin runs update_site.php and it checks for latest versions of all modules you have installed, if any are stale, it downloads, untars, installs, and invokes runs the update.php or something...).

the kind of stuff i'm talking about here is a slightly wider usage (maybe the distinction isn't helpful). this isn't *just* to ping people about new releases, but a place to discuss:

  • longer-term trends for the module ("i'm planning to move project_issue.module to be views-based, and provide some default views to mimic the existing UI for the issue queue, but allow people to customize/create their own -- would users of project_issue have a problem if it started requiring views.module in the future?")
  • soliciting feedback on features ("i just setup a poll at URL to find out how many of you actually use or care about feature X -- continuing to provide it is complicating the codebase, i'm tempted to drop support, but if there's outcry, i'll reconsider...")
  • prioritizing new work ("someone just proposed feature Y (URL to issue). this seems like a neat idea, but it'd be a ton of work and i don't see many use cases... would any of you actually use this if it existed?")
  • soliciting reviews/testing ("the 5.x-1.0-RC1" for eCommerce is finally ready -- please test it and help get the code ready for the official 5.x-1.0 stable release").
  • ...

then, there's also the issue of N to N (moderated) communication others have mentioned. e.g. some brilliant user of module foo just came up with a break-though use-case that's massively solved their problems, and wants to let others know about how they did it...

perhaps all of this should show up in the admin pages on your site, too, but that seems like a little bit overkill. plus, i'd kind of like to keep the release feed separate from the announce/discuss feed(s) to ensure that any automated tools to do intelligent things based on new items in the release feed don't have to filter out the wheat from the chaff...

finally, personally, i don't use RSS at all (yes, i know, i'm from the dark ages). ;) so, any of this stuff should also provide a way to just subscribe to a mailing list, instead, if that's how you like your data. one of the many reasons i'm leaning towards using OG for this...

___________________
3281d Consulting

profix898’s picture

I dont think a group for each module (using OG) is a solution for this. The main goal should be a possibility for module developers to get in touch with the module users. The users can easily contact a maintainer already using the issue queue or the personal contact form. Same is true for discussions on patches. But a module developer cant ask for user feedback atm.

  • Introduce a news feed (or news letter) and provide a form to let the user register for each module he/she uses.
  • It would also be helpful to have a 'sticky' feature (for maintainers only) for the issue queue. What means a maintainer could create an issue for annoucements etc.

A discussion group for modules only makes sense for large/important modules, e.g. ecommerce, but not for the smaller ones IMO. It might also be very exhausting for a maintainer to keep the issue queue, the project documentation, the group and ... updated.

greggles’s picture

So, you say you don't want to use OG, but you want: news feed/email where you can register for your modules.

A news feed/email where you can register for your modules IS OG!

The sticky feature kind of makes sense, but why not just use sticky in the OG?

Greg

--
Knaddison Family | mmm Beta Burritos

greggles’s picture

Well, canen and I are testing out the idea in a combined Path, Pathauto, Urlify group. We linked to it from the project page for both groups.

Based upon this test run we'll see how it goes and whether this is something that should be done across other groups.

--
Knaddison Family | mmm Beta Burritos