[WG: I18N & L10N] [Building Sakai] Shouldn't bug reports be easier to read for humans?

[Jean-Francois Leveque]

Given the input, that's what I'm gonna code.

Don't know when I will but I still intend to and hope the parts of the 
code that are more critical will be explicit and the review process 
defined so I can confidently contribute and be reviewed not too late 
afterwards.

I can patch locally but don't want to fork too far from the community 
code. Having contributions merged when they're good is part of the best 
things we can do together.

J-F

On 17/07/2013 20:00, David Adams wrote:
> Perhaps the safer way to address the problem would be to add new
> fields to provide the human readable dates you are looking for and
> leave the existing fields intact.
>
> -dave
>
> On Wed, Jul 17, 2013 at 9:08 AM, Matthew Jones<matthew at longsight.com>  wrote:
>> Well, at Michigan we had a process to cc these bug reports to a special
>> mailbox, a script to parse them and put them into a database, then do
>> monthly reporting on them. Something like that would be based around this
>> date field being as it is. Ideally something like this would be built into
>> Sakai, but it was much faster doing it externally.
>>
>> I'm not sure if they're still running that actively, but you have to figure
>> someone out there might be.
>>
>> I agree with Aaron, it is a high profile area, but someone would review and
>> commit any code that you provide. The ideal is that every jira is
>> verified/reviewed either by a developer or QA depending, usually depending
>> on the test plan or how extensive the changes are.
>>
>>
>> On Wed, Jul 17, 2013 at 4:19 AM, Jean-Francois Leveque
>> <jean-francois.leveque at upmc.fr>  wrote:
>>>
>>> I'm personally not aware or reasons to preserve the old values, that's why
>>> I was asking. Unless I get answers from people who need the old values to be
>>> kept, I won't.
>>>
>>> I'm adding the production list now to reach a larger audience who might
>>> need the old values.
>>>
>>> Unless this part of the code is subject to review like kernel because
>>> changes are known to be risky, I think I can handle it myself.
>>>
>>>
>>> On 17/07/2013 04:12, Matthew Jones wrote:
>>>>
>>>> Agreed. If it's important to you, submit a patch or contract with a
>>>> developer/commercial affiliate to have it resolved. Would be a few lines
>>>> of code and a few new message strings.
>>>>
>>>> The code is somewhere in
>>>>
>>>> portal/portal-util/util/src/java/org/sakaiproject/portal/util/ErrorReporter.java
>>>>
>>>> I think you'd want to preserve the old values in-case anyone is using
>>>> them and append new values like Created (formatted)
>>>>
>>>> Unless it's a high priority bug (breaks tool functionality) or a desired
>>>> local feature, generally it could take a while until it gets resolved.
>>>>
>>>>
>>>> On Tue, Jul 16, 2013 at 9:17 PM, Poindexter, David Ray
>>>> <davpoind at iupui.edu<mailto:davpoind at iupui.edu>>  wrote:
>>>>
>>>>      Dev resources, I'm guessing.
>>>>
>>>>      --
>>>>      David Poindexter
>>>>      Sent from my mobile
>>>>
>>>>      On Jul 16, 2013, at 10:49 AM, "Jean-Francois Leveque"
>>>>      <jean-francois.leveque at upmc.fr
>>>>      <mailto:jean-francois.leveque at upmc.fr>>  wrote:
>>>>
>>>>       >  Hi,
>>>>       >
>>>>       >  I've created https://jira.sakaiproject.org/browse/SAK-22022 as a
>>>>      feature
>>>>       >  request some time ago.
>>>>       >
>>>>       >  Do we have reasons not to do this?
>>>>       >
>>>>       >  Cheers,
>>>>       >  J-F