]> sipb.mit.edu Git - ikiwiki.git/blob - doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn
(no commit message)
[ikiwiki.git] / doc / todo / allow_option_for_requiring_description_when_editing_page.mdwn
1 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.
2
3 > Duplicate of [[todo/Allow_web_edit_form_comment_field_to_be_mandatory]] where
4 > Joey indicated that he didn't want this in ikiwiki core, but would
5 > accept a plugin that did it.
6 >
7 > Expanding on what Joey said there a little, the problem I have with
8 > *requiring* a commit message is that solving a social problem
9 > by technical means rarely works. If you can't persuade users
10 > to obey a policy like "provide a nonempty commit message", then
11 > you can't persuade them to obey a policy like "provide a *useful*
12 > nonempty commit message" either. I used to work on a project
13 > whose Bugzilla had been configured or patched to require a comment
14 > whenever you changed a field (e.g. priority, cc, ...) and in
15 > practice that just led to a lot of wasted time when people tried
16 > to triage bugs quickly, and a lot of comments whose text was
17 > ".", " ", or on at least one occasion, ☃
18 > (U+2603 SNOWMAN).
19 >
20 > If your chosen RCS has a technical constraint that the commit
21 > message must be non-empty (and will just not work otherwise),
22 > that's another matter; I'd say that in that situation
23 > it's appropriate for its plugin to replace empty commit
24 > messages with "." or gettext("update") or something. --smcv