From a4d3db605a921b6c99d1b5082450090e31911afc Mon Sep 17 00:00:00 2001 From: smcv Date: Mon, 30 Jun 2014 05:41:06 -0400 Subject: link to older bug; practical issues exist --- ...or_requiring_description_when_editing_page.mdwn | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn b/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn index 4fe591a48..bb8524841 100644 --- a/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn +++ b/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn @@ -1 +1,24 @@ allow option for requiring description when editing page. This is so if a commit to an rcs is used, the commit message will not be blank. + +> Duplicate of [[todo/Allow_web_edit_form_comment_field_to_be_mandatory]] where +> Joey indicated that he didn't want this in ikiwiki core, but would +> accept a plugin that did it. +> +> Expanding on what Joey said there a little, the problem I have with +> *requiring* a commit message is that solving a social problem +> by technical means rarely works. If you can't persuade users +> to obey a policy like "provide a nonempty commit message", then +> you can't persuade them to obey a policy like "provide a *useful* +> nonempty commit message" either. I used to work on a project +> whose Bugzilla had been configured or patched to require a comment +> whenever you changed a field (e.g. priority, cc, ...) and in +> practice that just led to a lot of wasted time when people tried +> to triage bugs quickly, and a lot of comments whose text was +> ".", " ", or on at least one occasion, ☃ +> (U+2603 SNOWMAN). +> +> If your chosen RCS has a technical constraint that the commit +> message must be non-empty (and will just not work otherwise), +> that's another matter; I'd say that in that situation +> it's appropriate for its plugin to replace empty commit +> messages with "." or gettext("update") or something. --smcv -- cgit v1.2.3