[Fwd: [Fedora Project Wiki] Update of "Artwork/ReleaseGraphics" by DianaFong]
Diana Fong
dfong at redhat.com
Thu Dec 21 22:38:29 UTC 2006
Máirín Duffy wrote:
> Diana Fong wrote:
>
> Also word-for-word notes that I wrote for the ThemingOverview page
> somehow leaked in (eg notes on testing GDM themes) and were
> miscredited. Don't worry though, I've removed my contributions so you
> don't have to worry about that anymore.
Looks like you missed a few.
> (1) that's not the way wikis work, if you've signed the CLA you don't
> need permission to make modifications and improvements to pages,
>
> (2) the specifications you contributed yourself had errors so
> obviously you're not fact and error-checking before you post things
> (check the history of ReleaseGraphics) and you did not discuss your
> plan with the list before going ahead and just doing it,
>
> (3) there are others on the list perfectly capable of fact-checking
> with either RH package maintainers or upstream package maintainers.
> Creating and discussing theme elements and their specifications is not
> that complicated. I've discussed GDM theme issues with Brian Cameron,
> the upstream maintainer of GDM, and discovered our themes up to this
> point have had accessibility issues we should address for FC7. This is
> an open community and people aren't really that hard to get a hold of.
In (1) you say permission isn't needed and then in (2) you say i needed
to check before doing. I checked information with the people directly
involved with taking the graphics on the Desktop team for our specific
distro. Fact-checking by others is fine, but as I also follow these
specs for RHEL graphics and the last two FC releases, it would be
advantageous to check with me and our engineers as we are the people
responsible for the end product. And if, as you say in (3) is true,
that this is an open community and people aren't really that hard to get
a hold of, then it should not be a problem.
>> Being that this directly relates to my role within Red Hat's Desktop
>> Group (as I go through this process several times for RHEL releases)
>> I will ultimately be the one responsible for providing the team with
>> the necessary usable graphics. Therefore, if the creator
>> follows the specs I've complied on that page, I would be responsible
>> in seeing that it works for the engineers and any errors would not be
>> of the creator who had followed my recommendations.
>
> I don't really see how that has anything to do with these wiki pages.
> Ok, so you want us community folk to submit art that makes it easier
> for you to prepare to hand it off to the engineers. That's cool. Why
> not do this on the community-created and contributed page on the wiki
> rather than creating your own bubble?
If also by submitting patches for applications you are also making it
easier for the maintainer...then yes, I want for there to be as little
incompatibility and missing images as possible when I approve the images
and hand it off to the engineers. It's no different than when
submitting source code patches to a project maintainer; there's review
and ping-pong to ensure that it fits in with the rest of the codebase.
My own bubble is comprised of the Red Hat Desktop Engineers which, like
myself, have themed several releases. All the information combined to
make ReleaseGraphics was to provide the Fedora Artists with a better
understanding of what is needed by people who do this regularly.
>> And so with deviations and personal comments, I take responsibility
>> of the content of the page with Release Graphic information separate
>> of all other specs that a general ThemingOverview page should
>> include. The page includes pieces from many people, I did not credit
>> nor do I take credit.
>
> "These are the notes and specifications I've accumulated from having
> completed 4-5 release designs." --Artwork/ReleaseGraphics
Precisely...notes and specifications I've accumulated from having
completed 4-5 release designs.
Diana Fong
---
Red Hat
Visual Designer | Desktop Group
More information about the Fedora-art-list
mailing list