For anyone here who doesn't know me, I'm Máirín Duffy and I'm an
interaction designer with Red Hat (I work on Red Hat Network -
I heard that you folks are building a bunch of infrastructure
applications and would like them to have a consistent look and feel, and
I would be very interested in helping out in this effort. I have a
couple of questions about the project:
- How many applications are involved, and what's involved? Is there an
exhaustive list somewhere with kind of a basic description of what each
- Which applications are highest priority to receive design/skinning work?
Based off of these I think the next steps would be for me and maybe some
other designers (I will try to recruit some :) ) to look over the
applications in question, considering their priority, and start putting
together some mockups for their look and feel. Then we can share the
mockups and start discussing their implementation here, and tweak them
where there are implementation concerns, and then finally figure out or
start implementing them (once there's an initial set of mockups the
design/implementation processes can kind of happen in parallel, as
implementation issues crop up we can go back to the designs and tweak as
needed, so on and so forth.)
Does this sound like a good plan?
I'd like to introduce myself. My name is Craig Thomas,
and I am an experienced LAMPhp developer very
interested in helping to develop the UI's of the
various infrastructure applications using the
TurboGears framework (and anything else I can). I've
done a tiny bit of work on the kid templates and css
in smolt, and I have been learning enough python to
get in trouble with the rest of smolt :) so kid
templates seem a natural fit to start with.
I first used redhat 7.2 for lamp work and have been
using FC as my desktop of choice since rh8. Until now,
I've just been a luser lurking in the mailing lists
and, lately, IRC. But I would like to change that and
get more involved; actually contribute something. I've
come to realize how much I depend on this whole
process to produce the OSes and applications I depend
on everyday to do my job. The least I can do is help
in the ways I can.
Err, thanks for listening?
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
Hey guys, can you check out ppc[1-2] when you get a sec? They didn't
come back up after a reboot, we've tried cutting power, the cyclades,
the ppc1-sp and ppc2-sp interfaces but nothing. Also ppc3 is up but the
ppc3-sp interface isn't working.
I'll be doing a wiki upgrade from 8:00 a.m. to 5:00 p.m. (CST) on
February 21st (Wed). I'll be trying to minimize downtime and, in
theory, the wiki won't every be unavailable, just un-writeable. During
our tests it has been determined that there are very few changes that
need to be made so we'll just fix things as they come up.
I've been looking at a bunch of config management systems and have
decided we should take a closer look at puppet. As far as config
management systems go. It doesn't suck, which is really saying
something. Plus we have experience in it in the group already. I'm
going to install it on lockbox and deploy configs on the app and proxy
servers for us all to look at. If we decide that we don't hate it, I'll
continue converting the rest of the systems.
Some members from the L10N project have identified some issues that need to be
solved to make sure the translations of Fedora are of high quality. Some of them
are infrastructure-related and at today's (-admin) meeting it was suggested to
transfer the discussion here.
I'm sure the folks at Red Hat are doing their best to keep the quality of the
translations high. But the truth is that Fedora's image in the context of
translations is not good; we do hear that a lot, from current and wanna-be
members. We can and should work to improve it. Semi-translated applications are
U-G-L-Y and shout "low QA" in our ears.
Some possible ideas have been listed on the following page:
Please feel free to chip in and help us out correct whatever doesn't seem
reasonable, break tasks into smaller tasks etc.
The bigger picture of some of these problems are:
* L10N of "local" applications (those listed on ) is poor; releases and
package updates contain untranslated strings in many languages. This is
unacceptable for a fully-localized desktop.
* The barrier to contribute to the l10n (be it GUI or Docs) is higher than it
should be (compared to other projects).
* QA of the translations is difficult with the current tools.
Some more concrete ideas to discuss that might concern the InfrProj and the
RelEng team are:
* Integrate better the handling of translation during a "local" package's
lifecycle. Have a flag raised for a package update that introduces new strings
so that translators can translate the new strings before the
repackaging/updating. Include in the schedule for each release a "string freeze
date" and a week later a "translation freeze date" and have all our packages
rebuilt after the latter and before the actual release.
* Move po files on their own cvsroot on cvs.fedoraproject.org to reduce
complexity and maintenance and to increase security (with a new group).
* Move the i18n status pages to Fedora servers (Plone/Turbogears?). Include a
direct link to the pofiles from there so that new members can have something to
work on before getting cvs access.
* In the future, use Plone to automate the QA between team members (ie
coordinators can review translations etc).
* Start working with the complex and tricky path to upstream translations that
no distribution has tackled yet in a successful way. Bring our translators
closer to the upstream projects.
Hope some of the above make sense. :)
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
Any python coders out there want to help with some wiki code? I'm
posting to the list because anyone can do this, they don't need to
have done something before but do need to be serious about helping and
be a python coder.