Re: [development] Counting .info files [Was: Documenting contribs]
On 10/25/2006 7:52:03 PM, Chris Kennedy (chrisken@mail.utexas.edu) wrote:
Back to the original topic, I recommend that any project description revisions be conducted as informal "reviews" that are posted to the module's issue queue and can then be accepted, rejected, or modified by the maintainer. This preserves the contributors' autonomy while encouraging quality improvements. I do agree that the module descriptions are often of poor quality.
I gotta be honest here.. If I need to file and monitor an issue for every little change, I'm unvolunteering. That's entirely too much work. I went ahead and started this about an hour ago, starting at Z and working my way up. I made sure revisions was checked and notified the author of the one I made fairly substantial formatting changes to. If someone doesn't like what I've done, they can always revert it. Mostly all I'm doing is adding a break tag and maybe moving things around just a bit so the new teaser makes sense. I'm not completely rewriting their descriptions unless I find one that's just horrible and then I'll talk to the maintainer first. Michelle
"Michelle Cox" wrote:
This preserves the
contributors' autonomy while encouraging quality improvements. I do agree that the module descriptions are often of poor quality.
Autonomy, schmautonomy. This is not an issue of civil liberty. We're talking about lucid, coherent, accurate information displayed in a consistent way in a public space. It's called editing, and it's quite reasonable to expect that one's writing, when published to a distribution system, might be edited for clarity, consistency and style -- without any need to "tell you in advance", have an argument over grammar versus personal preference, or any other such thing. Drupal.org is a big, giant, unwieldly-in-places published "magazine" (i.e., "container") of written content. The application of a style guide, the involvement of editors and other kinds of "this need not involve a diplomatic meeting of the heads of egos" professional polishes should be expected, desired, and considered a fact of life for any published writer. I agree with Michelle about filing issues in the queue for simple edits to teasers/descriptions: no way, Jose. If a maintainer follows up on her or his project page then they will be quick to notice editorial or style changes. If they strongly wish to undo that editing work, then there isn't any real mechanism to keep them from simply undoing it. There is a balance needed between "freedom of self-publishing" and the need for a whole software system of great complexity to enforce some style guidelines, whatever they may be and however they may change over time. Various soft and hard policy decisions affect this relationship. Right now, the maintainer could put whatever she wanted there, whether it was intelligible or not (too often, it is not.) This is not the current debate, but it is relevant. In the "real world", you wouldn't even be writing or controlling the edits on your published documentation -- you would write your code and hand things off to a documentation department or staff. And you would be thankful to that staff because it meant you could do what you do best: write code. Filing an edit in the issue queue is a non-starter as far as organized style effort goes. That's already possible just by posting a "feature request" or other issue. Anybody can suggest that you go and edit this or that sentence, and they should, if they don't understand what you mean. But for some kind of planned clean-up and harmonizing, well, that's just not efficient and will never produce results. Maintainers should be overjoyed that someone will improve their description and help break the "I made it so I understand it perfectly" assumptions which tend to creep into self-written documentation as well as generally spruce up the copy. Anyway, it's not such a big "my rights, my rights" deal. It's publishing. -- inkfree
inkfree press wrote:
It's called editing, and it's quite reasonable to expect that one's writing, when published to a distribution system, might be edited for clarity, consistency and style -- without any need to "tell you in advance", have an argument over grammar versus personal preference, or any other such thing.
It's called wiki wiki and is a good thing. :-)
I agree with Michelle about filing issues in the queue for simple edits to teasers/descriptions: no way, Jose.
Seconding.
If a maintainer follows up on her or his project page then they will be quick to notice editorial or style changes. If they strongly wish to undo that editing work, then there isn't any real mechanism to keep them from simply undoing it.
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia. In that way, a maintainer (or any other interested) would automatically be informed every time a change is made. That is particularly important to make it possible to see small changes which otherwise could go undetected for a long period of time. I also would like to see reversion management of the pages, again very much like how it works on Wikipedia. What do you other guys say?
Maintainers should be overjoyed that someone will improve their description and help break the "I made it so I understand it perfectly" assumptions which tend to creep into self-written documentation as well as generally spruce up the copy. I agree. I was grateful when "inkfree press" gave constructive criticism on my writing <http://drupal.org/project/roleassign>. And I am grateful to Michelle for her effort.
Cheers, Thomas
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia.
yeah sounds good. this is a development mailing list so i assume you are a developer. get to it! the likely implementation is add 'subscribe to this node' feature to core. any less implementation (like a contrib module) is not likely to used on drupal.org -moshe
On Oct 26, 2006, at 7:49 AM, Moshe Weitzman wrote:
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia.
yeah sounds good. this is a development mailing list so i assume you are a developer. get to it!
the likely implementation is add 'subscribe to this node' feature to core. any less implementation (like a contrib module) is not likely to used on drupal.org
FWIW, the module "subscriptions" (with the 's') does something very like this. It allows you to subscribe to a taxonomy term, any individual node (with auto-subscribing your to your own nodes), or to a particular content type. HTH, Ricky
On Oct 30, 2006, at 9:21 AM, Richard Morse wrote:
the likely implementation is add 'subscribe to this node' feature to core. any less implementation (like a contrib module) is not likely to used on drupal.org
FWIW, the module "subscriptions" (with the 's') does something very like this. It allows you to subscribe to a taxonomy term, any individual node (with auto-subscribing your to your own nodes), or to a particular content type.
we also desperately want this functionality on drupal.org for: a) subscribing to individual project issues (without having to post the annoying "subscribing" followups all the time) b) subscribing to all release nodes from a given project i'd *really* like to avoid implementing these from scratch in project_issue.module and project_release.module, respectively. dries, killes, et al, can we open a discussion about running the subscriptions.module (or equivalent, if there's a better alternative in contrib already) on d.o, so i don't have to re-invent the wheel, just for the sake of being "inside" project*.module? thanks, -derek (dww) p.s. maybe we should move this thread to infrastructure@d.o... ?
i'd *really* like to avoid implementing these from scratch in project_issue.module and project_release.module, respectively.
well, you wouldn't do it there. you would do it so all node types could benefit but i get your point.
dries, killes, et al, can we open a discussion about running the subscriptions.module (or equivalent, if there's a better alternative in contrib already) on d.o, so i don't have to re-invent the wheel, just for the sake of being "inside" project*.module?
that discussion is easy - subscriptions module has some ugly code in it and needs significant cleanup. Ideally, the best parts are salvaged and submitted to core as a patch. i wouldn't run it on groups site, and i'm more aggressive than d.o. volunteers are encouraged to work up this patch. -moshe
On 31 Oct 2006, at 15:35, Moshe Weitzman wrote:
dries, killes, et al, can we open a discussion about running the subscriptions.module (or equivalent, if there's a better alternative in contrib already) on d.o, so i don't have to re- invent the wheel, just for the sake of being "inside" project*.module?
that discussion is easy - subscriptions module has some ugly code in it and needs significant cleanup. Ideally, the best parts are salvaged and submitted to core as a patch. i wouldn't run it on groups site, and i'm more aggressive than d.o. volunteers are encouraged to work up this patch.
I'd have to look at subscriptions.module first (don't turn out modules on drupal.org without a decent security review). That said, I'd love to have e-mail subscriptions in core -- even if it is a fairly naive implementation. -- Dries Buytaert :: http://www.buytaert.net/
On 31-Oct-06, at 9:46 AM, Dries Buytaert wrote:
On 31 Oct 2006, at 15:35, Moshe Weitzman wrote:
dries, killes, et al, can we open a discussion about running the subscriptions.module (or equivalent, if there's a better alternative in contrib already) on d.o, so i don't have to re- invent the wheel, just for the sake of being "inside" project*.module?
that discussion is easy - subscriptions module has some ugly code in it and needs significant cleanup. Ideally, the best parts are salvaged and submitted to core as a patch. i wouldn't run it on groups site, and i'm more aggressive than d.o. volunteers are encouraged to work up this patch.
I'd have to look at subscriptions.module first (don't turn out modules on drupal.org without a decent security review). That said, I'd love to have e-mail subscriptions in core -- even if it is a fairly naive implementation.
If we're going to go that route I'd rather see a general subscription framework (no, I'm not going to say "API" ;) in core. There are lots of other ways that a someone could be notified of subscriptions (i.e. Jabber/XMPP, etc). It'd be nice if things could tie in there. So a subscriptions framework would really just keep track of what nodes/ terms/etc are subscribed and offer a hook for implementations to do the notifying. Code is gold? :P -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 10/31/06, James Walker <walkah@walkah.net> wrote:
I'd have to look at subscriptions.module first (don't turn out modules on drupal.org without a decent security review). That said, I'd love to have e-mail subscriptions in core -- even if it is a fairly naive implementation.
If we're going to go that route I'd rather see a general subscription framework (no, I'm not going to say "API" ;) in core. There are lots of other ways that a someone could be notified of subscriptions (i.e. Jabber/XMPP, etc). It'd be nice if things could tie in there. So a subscriptions framework would really just keep track of what nodes/ terms/etc are subscribed and offer a hook for implementations to do the notifying.
Code is gold? :P
Subscriptions already does RSS as well. So it's somewhat close. But yes....the mythical someone needs to stand up and 1) do a code review and 2) file issues that need changing and 3) do the issues with code -- Boris Mann
I'd love to have e-mail subscriptions in core -- even if it is a fairly naive implementation.
I'd love to have RSS subscriptions in core :) See http://drupal.org/node/29524 /Anders
On 10/31/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 31 Oct 2006, at 15:35, Moshe Weitzman wrote:
dries, killes, et al, can we open a discussion about running the subscriptions.module (or equivalent, if there's a better alternative in contrib already) on d.o, so i don't have to re- invent the wheel, just for the sake of being "inside" project*.module?
that discussion is easy - subscriptions module has some ugly code in it and needs significant cleanup. Ideally, the best parts are salvaged and submitted to core as a patch. i wouldn't run it on groups site, and i'm more aggressive than d.o. volunteers are encouraged to work up this patch.
I'd have to look at subscriptions.module first (don't turn out modules on drupal.org without a decent security review). That said, I'd love to have e-mail subscriptions in core -- even if it is a fairly naive implementation.
Subscriptions (with an 's') is the best of a bad bunch. I won't comment on the code (it works, after all), but here's my list: Must have: * instead of just including a link to the updated content, allow for selection between title + link, title + teaser, and full update (same would apply to comments) Nice to have: * digest mode: allow sending of X updates and/or sending after Y days -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On Oct 31, 2006, at 6:46 AM, Dries Buytaert wrote:
I'd have to look at subscriptions.module first (don't turn out modules on drupal.org without a decent security review).
of course.
That said, I'd love to have e-mail subscriptions in core -- even if it is a fairly naive implementation.
sure. however, i'm sure we all want the functionality i described (and that which started this thread) much sooner than d.o will be running any pre-release of drupal 6.0 core (9+ months from now?), which is the earliest we'd see any of this stuff in a version of core running on d.o... if these email subscriptions get to the top of my drupal to-do list and no one else has done anything about it by then, i volunteer to review the various subscription-related contribs out there and do an initial audit of the most promising one. any help on these tasks would be *greatly* appreciated (so i can focus on things that require in-depth knowledge of the internals of the project.module, which only about 4 of us on earth have)... ;) thanks! -derek
Hello I think a general subscription framework may be the best Utopian solution. Or else some well thought out combination of modules (CCK + views + workflow + actions should offer it all), AND (in core) a *tiny*, specific subscription module, which solves only *one case* of subscription. Op dinsdag 31 oktober 2006 15:46, schreef Dries Buytaert:
subscriptions.module
Basic review of subscriptions module * Subscriptions are hardwired to nodes and comments. This hardwire-mistake is made once with the file-handling framework architecture. Lets not go there again. * Someone decided to hardwire 'blogs subscriptions'. This is far too specific. * user_mail is hardcoded into it. We all know this does not scale at all. The mailing engine should at least be pluggable. * Mailing vars (%tokens) are hardwired. If this is a general subscription system, that needs to be at least better configurable, but ideally the tokens alter-able by some hook(s). * Subscriptions offer no proper hookable points. Its either 'do as I say' or nothing. Ideally one can hook into various places in the subscription workflow and alter the send mails, alter who gets what etc. * The UIs are all hardcoded into the system. It depends entirely on the case, what a good UI has/is and where it is. Some options I think of OOTMH * subscribe to all stuff from user X * subscribe to comments for node X * subscribe to revisions for node X (wiki) * subscribe to a group of nodes (grouped by terms, tags, OGs, node types) * advanced subscriptions (where field F > X AND author.role in (admin, moderator) etc) Some more technical "asides" IMO a cached menu with a path ''path' => "user/$user->uid/subscriptions"' is plain wrong. "Unsubscribe from this node type. " We agreed never to use the word "node". And what the ** has a user/guest got to do with 'types'? Code style is very non-standard. It would need an almost 100% rewrite (style rewrite, notlogic) to be core-worthy. Code comments are inconsistent and need a big overhaul. I see a lot of fancy Superglobal usage and complex query-crafting. These are so fancy and so complex that after 15 minutes of staring, I can still not say if this is actually secure/safe. The fact one cannot review security well, itself, can be considered a security problem. Bèr
On Mon, 30 Oct 2006 12:21:07 -0500, Richard Morse <remorse@partners.org> wrote:
On Oct 26, 2006, at 7:49 AM, Moshe Weitzman wrote:
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia.
yeah sounds good. this is a development mailing list so i assume you are a developer. get to it!
the likely implementation is add 'subscribe to this node' feature to core. any less implementation (like a contrib module) is not likely to used on drupal.org
FWIW, the module "subscriptions" (with the 's') does something very like this. It allows you to subscribe to a taxonomy term, any individual node (with auto-subscribing your to your own nodes), or to a particular content type.
The subscription module (without a trailing "s") would probably be better, as it's built to allow plug-ins. I had great hope in it, though the plug-ins I expected to see (subscribing to comments and nodes) never appeared. -- Tim "This isn't my normal e-mail address" Altman
On 10/31/06, Tim Altman <operademo@gmail.com> wrote:
The subscription module (without a trailing "s") would probably be better, as it's built to allow plug-ins. I had great hope in it, though the plug-ins I expected to see (subscribing to comments and nodes) never appeared.
The subscription module has many problems and is basically unmaintained at this point. There's the review from someone using it on 2 sites and who is looking for a migration path away from it... Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
I've recently taken over maintaining the Notify module which does some basic notification of new nodes/comments. And, I've talked to the maintainer of "subscriptions" (with the 's') about merging these and doing a major code audit, so this is on my future todo list but will happen no time soon. I'd love to get rid of the cruft and have one solid subscriptions module to handle all this functionality. So count me in to help a bit on this. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Richard Morse wrote:
On Oct 26, 2006, at 7:49 AM, Moshe Weitzman wrote:
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia.
yeah sounds good. this is a development mailing list so i assume you are a developer. get to it!
the likely implementation is add 'subscribe to this node' feature to core. any less implementation (like a contrib module) is not likely to used on drupal.org
FWIW, the module "subscriptions" (with the 's') does something very like this. It allows you to subscribe to a taxonomy term, any individual node (with auto-subscribing your to your own nodes), or to a particular content type.
HTH, Ricky
On 10/31/06, Rob Barreca <rob@electronicinsight.com> wrote:
I've recently taken over maintaining the Notify module which does some basic notification of new nodes/comments. And, I've talked to the maintainer of "subscriptions" (with the 's') about merging these and doing a major code audit, so this is on my future todo list but will happen no time soon. I'd love to get rid of the cruft and have one solid subscriptions module to handle all this functionality.
So count me in to help a bit on this.
Adrian has responsibility around some of this as well. In particular, the whole "do what Notify does only in subscriptions" is one of them. So, great -- let's use the issue tracker to coordinate. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Maybe I'm missing something here, but if what you want is an RSS feed of nodes that you have flagged as "watched" when they change, it sounds like a trivial node that uses Views. I.e., have the module allow a user to flag a node as "watched", then create an RSS feed with Views that shows all nodes with a watched flag, with an argument for the user, ordered by modified time. It's just a tracker-like feed. Or am I missing something in the needed functionality? On Tuesday 31 October 2006 16:08, Rob Barreca wrote:
I've recently taken over maintaining the Notify module which does some basic notification of new nodes/comments. And, I've talked to the maintainer of "subscriptions" (with the 's') about merging these and doing a major code audit, so this is on my future todo list but will happen no time soon. I'd love to get rid of the cruft and have one solid subscriptions module to handle all this functionality.
So count me in to help a bit on this.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com
Richard Morse wrote:
On Oct 26, 2006, at 7:49 AM, Moshe Weitzman wrote:
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia.
yeah sounds good. this is a development mailing list so i assume you are a developer. get to it!
the likely implementation is add 'subscribe to this node' feature to core. any less implementation (like a contrib module) is not likely to used on drupal.org
FWIW, the module "subscriptions" (with the 's') does something very like this. It allows you to subscribe to a taxonomy term, any individual node (with auto-subscribing your to your own nodes), or to a particular content type.
HTH, Ricky
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 10/31/06, Larry Garfield <larry@garfieldtech.com> wrote:
Maybe I'm missing something here, but if what you want is an RSS feed of nodes that you have flagged as "watched" when they change, it sounds like a trivial node that uses Views. I.e., have the module allow a user to flag a node as "watched", then create an RSS feed with Views that shows all nodes with a watched flag, with an argument for the user, ordered by modified time. It's just a tracker-like feed.
Or am I missing something in the needed functionality?
It's slightly more complex than that, although the theory is the same. Currently, the subscriptions module also allows you to "watch" taxonomy terms (good for forums and for a subset of content on a site). The discussion here is -- go review the existing subscriptions module code, review it and give updates, improve as necessary, then get it installed on Drupal.org. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 10/26/06, Thomas Barregren <thomas@webbredaktoren.se> wrote:
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia. In that way, a maintainer (or any other interested) would automatically be informed every time a change is made. That is particularly important to make it possible to see small changes which otherwise could go undetected for a long period of time. I also would like to see reversion management of the pages, again very much like how it works on Wikipedia. What do you other guys say?
Feel free to write some code that is acceptable to run on core / be deployed on Drupal.org. Handbook pages get edited all the time, and it shows up in your tracker. Until someone puts serious elbow grease into a scalable solution, it ain't going to happen. Revisions are already there for all nodes, which you can see if you are a site maintainer. If anyone on this here dev list wants to do editing, join the docs list and ask for site maintainer privs. It helps to have submitted a couple of handbook pages that appear to be well written. For further references, see: about a billion past discussions on Docs list about code improvements that are desired. -- Boris Mann
Boris Mann wrote:
On 10/26/06, Thomas Barregren <thomas@webbredaktoren.se> wrote:
If we are encouraging people to edit each others module description (or handbook pages for that matter), I would very much like to see an opportunity to register for an e-mail upon change, very much like how it works on Wikipedia. In that way, a maintainer (or any other interested) would automatically be informed every time a change is made. That is particularly important to make it possible to see small changes which otherwise could go undetected for a long period of time. I also would like to see reversion management of the pages, again very much like how it works on Wikipedia. What do you other guys say? <snip>
Handbook pages get edited all the time, and it shows up in your tracker.
Yes, but that wasn't what I was talking about. I was seconding inkfree's position that anybody should feel free to improve any module description even if they aren't the maintainer. But as contributer of a module, I would however appreciate to know if the description of the module was changed, so that I can review such changes, and if necessary correct any mistake. But on the other hand it isn't feasible to ask for instance Michelle to send a notice herself for every little change she does. It was therefore I venture to think how nice it would have been if at least the module maintainer would get an automatically notice if anybody has made a change to module's description. It's no big deal. Just a rash thought.
Revisions are already there for all nodes, which you can see if you are a site maintainer.
Yes, but again that wasn't what I was talking about. I am the maintainer of RoleAssign <http://drupal.org/project/roleassign>, but I havn't access to previous versions of the description I have written. It's no big deal. But if we are encouraging people to edit each others module description, I thought it could be a good idea if at least the module maintainer, who after all is responsible for his/her module, would be able to revert any change if necessary. Regards, Thomas
participants (15)
-
Anders -
Boris Mann -
Bèr Kessels -
Derek Wright -
Dries Buytaert -
Greg Knaddison - GVS -
inkfree press -
James Walker -
Larry Garfield -
Michelle Cox -
Moshe Weitzman -
Richard Morse -
Rob Barreca -
Thomas Barregren -
Tim Altman