I 100% agree with Brian on #9, and #10. How about we set up a schedule and due dates for each of the doable goals for the next release. I propose we begin with boot. Followed by wallpaper contest. Then, once we are done with the important part we can seat back, relax and talk for ever and ever. Plus we will have some real life experience with Flickr and friends. Right now we are justs speculating, and wasting time.
So
1. Boot sequence [due date here]
2. Wallpaper contest [due date here]
Once we have the due dates we can draft the workflow within the existing time frames.
Lets go people.
Best regards,
Eugene Trounev
Bryen M Yunashko <suserocks(a)bryen.com> wrote:
>I have some grave concerns about the direction here, but also, I
>disagree that what is outlined here is actually about "12.3." This
>seems to be about a broader initiative that isn't 12.3 specific.
>
>More below:
>
>On Tue, 2012-10-02 at 20:28 -0600, Andres Silva wrote:
>> Given some of our member's suggestions, I have reviewed the list of
>> do's for 12.3. Please read carefully and give a vote if you agree with
>> the steps. If a majority agrees, we will start making the arrangements
>> for these tasks to see the light.
>>
>> 1 Encourage the use of raster images for wallpaper (Using Flickr
>> artwork pool to draw images)
>> Add more places for submissions (email, social networks, etc)
>> Use raster for the final wallpaper and not for its creation necessarily
>>
>This direction, as phrased, concerns me, but I think others have already
>addressed their concerns and I'd just be repeating...
>
>
>> 2 Flickr is used, make sure that the uploader is responsible for
>> the correct liscensing of the image (Provide information about
>> branding people's artwork)
>> Provide links for licensing images
>> Follow up with creators for their work and how they licensed it
>> Make a decision on what license works best for digital art
>>
>I personally dislike Flickr. And its size limitations per account have
>given some of us already a hard wall that we couldn't get out of without
>shelling some money out of our pocket. And because of the size
>limitations, posters will feel obligated to post a lesser-quality
>resolution in order to not run out of space.
>
>But more importantly, I think we should use Flickr, and all other social
>network outlets as a place of recruitment, not as a repository. We
>should engage these artists when we see their works (whether on Flickr
>or Facebook or elsewhere) and encourage/mentor them how to be more
>directly active as a contributor to the Project. Having the Project
>function *outside* of its infrastructure is a good way to actually lose
>control in the long run. And people *will* come when they have a place
>they can feel they belong.
>
>
>> 3 Create upload guidelines for artwork contributors (Although there
>> are some guidelines about this, there is no specific place for
>> copyright in the wiki)
>> Create a wiki page for explaining licensing
>> Promote licensing on our submission areas (Flickr, social networks, etc)
>>
>Unless you specifically hand it over to another entity, all works are
>automatically owned by the creator. So copyrights aren't really the
>concern here. And unlike some other projects, we don't really encourage
>copyright assignment. It is anathema, really.
>
>What is more important is to understand sources within the artwork.
>We've had some cases where we thought the contributor completely created
>a piece, only to find out it was a compilation of components from other
>places. Contributors need to provide some kind of a trail so when
>artwork is selected to represent openSUSE, we know the actual history
>behind it. We need a way to inspect and verify, just like our OBS has an
>inspection process to ensure proper licensing.
>
>It would be serious egg in our face if someone created a wallpaper that
>we all loved and selected as our default, only to find out after release
>someone shouting "Hey!!! That image is from another place, you guys
>aren't orginal at all!" Even if that component was completely
>open-licensed, not knowing that a piece isn't original makes a world of
>difference.
>
>> 4 Change default font to OPEN SANS on KDE. (This font family is extensive
>> and looks extra sharp on both KDE and GNOME, use full rgb subpixel
>> rendering on KDE by default)
>> Start with KDE first and then decide if it will work properly on Gnome
>>
>
>As already mentioned by others, I hope this is something you intend to
>discuss directly with those teams. We've already encountered in the
>past where members of those teams were upset with artwork team intruding
>on work that was already put into this and not even any prior dialogue
>before attempting to throw out their work for the artwork team's.
>
>Some important political diplomacy is needed here before setting out on
>such initiatives.
>
>
>> 5 Change Plymouth to a progress bar with a sparkling end (per
>> request of some contributors and to keep a simple elegant
>> understanding of the boot process, more details to come)
>>
>
>I must have missed this discussion. The one I recall is the one Jos
>started with how to retain our beloved seasonal grub screen change.
>(The one where the Penguins are like lemmings across the top of the
>menu.) That is a very popular feature, and as Eugene pointed out, it is
>possible to restore that and even more, to provide *MORE* seasonal
>options. I would suggest make sure this popular feature is put back in
>before moving on to other ideas.
>
>There is an accessibility problem with the basic screen we have now, and
>that should also be addressed. Providing some usability testing for
>important screens is something that needs to be considered. While I
>respect an artist's right to be creative wrt to their creations, the
>artwork team primarily functions as a service enhancement to the
>openSUSE product line.
>
>What that means is while artwork should be awesome and beautiful, it
>should not interfere with the actual usage of the underlying product for
>our users, regardless of accessibility needs or otherwise.
>
>> 6. Change/improve styling on YAST
>>
>
>This isn't a 12.3-related subject. Unless you are proposing to do a
>restyling for every release? If so, that's a huge outlay of resources
>to reinvent the wheel every time.
>
>But bottom line, I don't think this should be a team "TODO" but rather a
>"Just Do It." I'm not a 100% fan of that slogan, tbh, but in this case
>it is apropos. The biggest problem we have historically in communities
>like ours is everyone getting into a discussion "Oh, this should be
>changed, that should be changed, blah blah blah" and in the end, nothing
>ever gets done. A few months later, same discussion pops up. Same
>endless quicksand cycle. Year after year...
>
>We end up in quicksands with these kinds of myriad discussions. The
>best results in any and every case I've seen is when someone simply has
>a vision and just DOES it! Then says to the team "Whaddya think?" You
>get good feedback on concrete things to discuss rather than
>hypotheticals.
>
>You've mentioned this idea for a long time. Surely, by now you have an
>actual vision in mind. Show the team your vision even if its just
>mockups. That's the surefire way to move this forward. People want
>something tangible they can look at and comment on.
>
>> 7 Change KDE splash screen to match Plymouth
>>
>I don't like things that match from bootup to desktop. You stare at the
>screen wondering if your desktop is ready and then moments later go "oh,
>it is ready, I didn't notice the change." I prefer that each stage have
>its own unique look and give truer distinction. And I know I'm not the
>only one who has felt this. Many people have expressed confusion.
>
>> 8 Keep default splash screens for applications
>>
>This is good.
>
>9. Yes I'm adding one here. The most important thing in the TODO list
>that didn't get mentioned. Creating a checklist of what needs to be
>done before release of 12.3. Sorry but, this past 12.2 release, was
>really bad in terms of timely artwork delivery. While several of us
>mentioned what needs to be done, no one responded and then at the last
>minute everyone scrambled. This checklist is the most important
>fundamental thing you need in order to plan and schedule tasks. And it
>should carry over to be re-used in future releases to refer to. As long
>as such a list is present, people can go in and check out do-able tasks.
>
>And contributors are frequently much more likely to respond to specific
>tasks rather than broad strategic discussions. Leaving out the list
>severely disenfranchises such contributors when we need them the most.
>
>10. And one more... Focus on more results-oriented goals and
>deliverables. To be honest with you, my go-to guys to get some request
>filled out are Marcel, Richard and Victor. Those are the guys I know I
>can reliably count on to approach, hand in a concept to them, they'll
>work through it and usually in a few hours come back with an initial
>design which we can further tweak.
>
>That ability to respond and to understand the requestor's needs and
>deliver is a key component that will help make this team grow. There
>are lots and lots of artists worldwide who are not interested in
>strategic discussions. They just want to create. You make the team
>more inviting and easy-entry, and you'll get a LOT more Marcel's,
>Richard's and Victor's, I guarantee you that. Because people will want
>to go where their work is appreciated and desired.
>
>There's a huge amount of requests over the years that have gone
>unanswered because we simply don't have the broad breadth of talent we
>need to address various needs. That's something that needs to be worked
>on.
>
>Some of those that we get in the door may eventually evolve to handle
>bigger tasks and goals like the ones you have mentioned. But you gotta
>get them in the door first. :-)
>
>Bryen
>
>
>
>
>> Thank you
>> Andy (anditosan)
>
>
>--
>To unsubscribe, e-mail: opensuse-artwork+unsubscribe(a)opensuse.org
>To contact the owner, e-mail: opensuse-artwork+owner(a)opensuse.org
>
