Proposal:don't send mail from pages whose name ends with "Draft"
Created:2006/03

We don't send mail from "boring" pages (or from empty comments, a different mechanism). isBoring() decides which these are, currently it is any pages below 'TestPage' or 'SandBox'. We could say any page whose name ends with 'Draft' should be considered boring and therefore not send mail.

This is motivated by eg the ProposalsProcess, the goal is to make it easier to draft a new page yet not mail it out until it's ready. At present you have to create the page under SandBox, it would be a little easier on the brain if you could just create it in the right place, call it somethingDraft, flesh it out and rename it when you are ready to have subscribers see it.

Pro:

Con:

workflow? --Bill TestPage, Thu, 23 Mar 2006 09:19:08 -0800 reply

I agree that using renaming to accomplish this is awkward.

Although this smacks of adding some "workflow" functionality, I think the best approach would be to provide a 'Draft [ ]?' checkbox on pages where this feature was enabled. This makes it compatible with I18N. Checking the 'Draft' option on the page would make changes silent (except for people who are direct subscribers to the page). Removing the check mark and clicking 'Save' would mail out the whole text to wiki and page subscribers as if it had just been created.

Questions:

1 Should it be possible to return a page to 'Draft' state once it has been saved as a non-draft?

2 Should it be possible to exclude 'Draft' pages from the view of users who have not identified themselves in 'options'?

workflow? --Phil Schumm, Thu, 23 Mar 2006 10:35:56 -0800 reply

I must say, I prefer Bill's suggestion. One other problem with the "pages ending in 'Draft'" strategy is that it is one other thing new users would have to learn (the checkbox would be both "self-documenting" and "self-reminding"). RE (1), I don't see why returning a page to the draft state would be bad, and in some cases might be very useful (e.g., during intensive editing sessions). RE (2), I'd vote against.

BTW, we're just in the process of migrating all of our sites to Plone, and so I'm for the first time realizing how wonderfully ZWiki works within Plone. Clearly, integrating ZWiki notification into a workflow would be optimal for Plone users. I suppose, however, that this would somewhat disenfranchise those who don't use Plone...

workflow? --Simon Michael, Thu, 23 Mar 2006 13:43:46 -0800 reply

Thanks for the input. At the same time, we don't want to make it too easy to avoid mail notification or it defeats the whole purpose of it for wiki monitoring. At least the all-edits subscribers should see everything, it shouln't be possible to spam the wiki without them knowing.

I forgot to mention another case where we don't send mail: when creating an empty page. I use this all the time, eg when archiving discussions: create the empty page first, then edit and paste in the content. The ordinary subscribers will hear nothing. In this case, how to send it out to them when it's ready ? I could delete the page and recreate it, this time with the text in place. They would see a delete notification. Or I could empty the page and paste the text again as a comment, then edit to remove the comment heading. The all-edits subscribers would see the page content a second time, either way.

wiki monitoring --Bill TestPage, Thu, 23 Mar 2006 14:13:50 -0800 reply

I think monitoring is a different function than subscription. Do we really need to worry about spammers who create boring pages? Perhaps, yes. But I haven't seen this happen yet. Maybe they are interested in link counts but then boring pages should also normally be referenced only via "nofollow" links I think.

Right now the 'all-edits' subscribers do not see changes or new page additions made to boring pages, right? I think that is a good design and it should be the same for 'Draft' pages. This allows two levels of subscriptions.

But monitoring via email requires that one receive a notice of all changes and additions - even those made to boring pages. Persumably only those people tasked with managing the wiki would be willing to put up with this - e.g. 32 different versions of the same page while I try to get the StructuredText just right. :), though perhaps it could be offered as a subscription option. On the other hand I would be happy to have this specified by a property that is configured via ZMI.

wiki monitoring --Simon Michael, Thu, 23 Mar 2006 15:39:16 -0800 reply

> Do we really need to worry about spammers who create boring > pages? Perhaps, yes. But I haven't seen this happen yet.

Bill - yes, we do. Public zwikis are being ever more spammed and this will only continue. It needs to be resistant to such things out of the box.

> Right now the 'all-edits' subscribers do not see changes or > new page additions made to boring pages, right?

No, they see everything including boring edits (possibly excluding empty page creations). That's by design!

> Persumably only those people tasked with managing > the wiki would be willing to put up with this - e.g. 32 > different versions of the same page while I try to get > the StructuredText just right. :), though perhaps it > could be offered as a subscription option. On the other > hand I would be happy to have this specified by a property > that is configured via ZMI.

I once thought the same. We used to have this (mailout_policy property). When I implemented the two subscription levels, things became very complicated with backwards compatibility, synchonizing with the subscribe form, page vs. whole-wiki mail and especially trying not to create confusion for users. The one property almost became several. I came up with the present simple design which I feel was a pretty good solution. Yes sometimes as an all-edits subscriber you get too much mail - if you're not used to those kinds of quantities - but it does say "all edits", and it's easy to downgrade your subscription when it turns out to be too much.

all-edits --Bill TestPage, Thu, 23 Mar 2006 15:51:10 -0800 reply

Oh. I guess I am used to the old 'mailout_policy' functionality as we still use it on http://wiki.axiom-developer.org . Do you mean this is gone? What do subscribers see if they do not click "all-edits"? I thought "all edits" was the same as overriding the default 'mailout_policy'. If not, as a wiki implementer how can I control this?