Brainstorming tasks for next sprint

Tomas Sedovic tsedovic at redhat.com
Fri Feb 17 17:38:54 UTC 2012


On 02/17/2012 06:34 PM, Jason Guiditta wrote:
> On 13/02/12 16:06 -0500, Matt Wagner wrote:
>> Hi all,
>>
>> As we start to wrap up bug-fixing, I was hoping to get a conversation
>> going about what we need to tackle in upcoming sprints.
>>
>> What else do you think we should try to focus on?
>>
>
> Two more to put on the hopper:
>
> == 1 ==
>
> I think something that should get fairly high priority is what I am
> calling 'lightweight theming support'. Basically, we need to enable
> our customers (like red hat) to apply their own 'flair' (preferably
> more than the minimum number of buttons, but if that is all you
> want...). They should be able to do this without having to make
> changes directly to our code. The simplest way I can think of to do
> this is to add 'theme' subdirectories to css, images, and maybe even
> javascript dirs. Conductor then optionally loads files from
> there if they exist. As anyone working with css knows, you can easily
> override defaults this way, and do it cleanly. One specific (and
> fairly minor) change that would benefit from this approach is the
> handful of haml files using image tags that pull in things with
> '-upstream' appended to their names. With this approach, those would
> be pulled in via css, and any branding would be done simply by adding
> a new image/css override in the appropriate 'theme' subdirectories.
>
> == 2 ==
>
> i18n files should be split into a logical structure[1] instead of having
> one monolithic file as we do now. The patch that I recently pushed to
> master adds support for this, so it would be nice to get a little
> cleanup in here next sprint. This is a pretty simple task/feature as
> well, just needs a little time for someone to run through and make the
> changes.
>
> -j
>
> [1]
> http://guides.rubyonrails.org/i18n.html#organization-of-locale-files


Speaking of i18n files (I agree with both points you raised btw), they 
deserve a general cleanup anyway.

There's at least a bunch of entries that we no longer use and others are 
horribly duplicated.

Sorting this out would go along nicely with the reorganization effort 
since we'd be touching the entire structure anyway.



More information about the aeolus-devel mailing list