Dan Langille wrote:
> Kern Sibbald wrote:
>
>
>> To everyone:
>> In the future, please (everyone) pay careful attention to formating your
>> request (i.e. leading spaces, line separation and such) so that it
>> corresponds exactly to the format in the projects file. As these are
>> presented, they are almost unreadable when copied and pasted into the
>> projects file, and so to make it readable, I have to spend considerable time
>> dealing with formating. If you do not understand what I mean take a look at
>> the current project file and try to find and read some of the more recent
>> submissions.
>>
>> Thanks for your consideration of the request.
>>
>
> I suggest a slight change of policy.
>
> If a request is accepted, but is in the incorrect format, it should be
> put on hold until the submitter adjusts the format. It is in their
> interest to reformat.
>
> I say "accepted then reformat" because there's no sense in asking
> someone to reformat if it's been rejected.
>
> Of course, I'd also go for "reject the submission if incorrectly
> formated". I think shifting the work to those better suited to carry
> out the work is a good idea.
>
> Developers are not expected to do a bunch of text formating. It's not
> because they can't do it. It's because others can easily do it, thus
> freeing up developer time to do developer things.
>
I'm not sure that the submitters are any better suited to do it, because
it isn't clear at all that the formatting is *that* critical, or exactly
what the format even is. http://www.bacula.org/en/?page=feature-request
describes it, but the way I read it, all it says is which fields you
should put into the feature request. From looking at it, I wouldn't have
known that the Origin and Date field should be intended two spaces (or
is it three?) If it is this critical, maybe you could make that explicit.
Another issue is that it may be impossible to meet that requirement.
Looking at it, it seems that the misformatting in the line breaks that
prompted Kern to suggest this policy actually was an artifact of the
email MUA or a message transport somewhere along the way. That *will*
happen regularly, in particular when emails are going back and forth
discussing the feature request.
How about creating a form on the Web site that accepts the various
fields and automatically generates a perfectly-formatted feature request
and emails it to the appropriate mailing list? Put a CAPTCHA on it to
prevent spam, and the problem is mostly solved (misformatting could
still happen while the feature request is being discussed, of course,
but at least the initial request would come out perfectly every time).
--
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Network You Never Have to Think About
Office: 866-642-7116
http://www.4nettech.com
This e-mail and attachments, if any, may contain confidential and/or
proprietary information. Please be advised that the unauthorized use or
disclosure of the information is strictly prohibited. The information herein is
intended only for use by the intended recipient(s) named above. If you have
received this transmission in error, please notify the sender immediately and
permanently delete the e-mail and any copies, printouts or attachments thereof.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
