Additionally, I have been asking some members of our team about the possibility of them taking a specific responsibility on the team to streamline our work.

If it is easier for people to work together in this way then that's ok, just understand that it takes away from other people who may wish to participate in that area. While focus is primarily to make sure imperative steps get done it is just as important to be transparent to the team. It's always good to have 2 or more team members assigned to various roles as backup to each other in case one can not deliver for whatever reason such as vacation, broken computer or any other unforeseen obstacles. I'm sure Andy remembers when he had no access to his SmartGit and was working from his tablet during this last release. At the university we take on various roles to complete our team assignments and it works pretty well since we know who needs to work on what and submit to who for the next phase of the process. We also make sure that there is some overlap in our assigned positions "just in case" someone needs to step in for someone else. Always CYA!

Next thing is to start work on a flow diagram for artwork team, from question (request) to having artwork delivered.

This is an AWSOME idea. I've been thinking to myself that ML and IRC really aren't enough to create a good workflow distribution to a team. Where do we go to see what needs to be done, who is working on what and what is left to be done? I think there should be a maintained (Team Leader) wiki page or shared document for this kind of thing. I don't have all day to hang out in IRC to see if I can pick up on a project. Mailings can get lost in transmit, unintentionally deleted and all kinds of things. If I have time to contribute some work that would be beneficial and I have a bookmarked page I can go to then I can quickly see this is done, that is done, this needs to get done but someone is already working on it and so on and so forth. If I want to pick up a project I could do so from one page and let Andy know that I'm working on it and should have it done by such date for approval. If it needs tweaking and I don't have time then someone else can pick up the core files from a link and tweak the image to liking by the team or whoever is the customer. This way everyone on the team knows who is doing what so we don't step on each others toes and things don't get missed.

Also, nothing prevents us from starting on next release N+1 when we are done with N, which should happen for most us 2 moths before official release day.

From my chair it looks as though Andy is already on this, but it makes good sense to have a lot of things in motion as of day one after release. With the progression we are making with scheduling logistics I foresee a HUGE improvement over the way we did things during this last release with last minute Oh No's! almost eliminated. The work to be done for each distribution doesn't seem to change much with each roll out, however the work for social media, marketing things like T-shirts, coffee mugs, beer mugs, brochures, and stuff changes all the time. As we begin to build an accepted way of providing a resource for our customer departments to view a collection of works in a logically categorized manner with links to core files, the amount of new work required from the team may drop off and all anyone will need to do is make changes to something pre-existing from the collective pool. I've played with this a little and found that GitHub, DropBox and Google Drive make good storage places for SVG and XCF files that can have link access to a thumbnail anywhere which means that we can build a huge library within the wiki with links to an almost unlimited amount of storage provided by each of the team members collectively. Our client simply looks through the library and finds an image they like then downloads the core files for use in their project or asks the team leader to have the files modified to their liking which then gets assigned to a team member to get done.

Regardless, I'm seeing a lot of positive work getting done these last couple of weeks. Excellent jobs done by everyone and I'm thrilled to say I'm part of openSUSE! On Sat, Oct 6, 2012 at 10:21 AM, Rajko wrote:

Why did I split all in sections? Because it is easier for me to track answers and to allow simple split in subthreads.

What do you think about this?

On Fri, 5 Oct 2012 11:08:29 -0600 Andres Silva wrote:

------------------------------------------------------------------------ 1)

...

We have had a few conversations about some upcoming changes ...

---

2)

...

Also, the wallpaper contest is about to be launched. ... Kenneth will likely need the help of our team since he is short on time. Let's be ready for his requests.

He already did good job with one of his emails explaining all point that we should consider when setting up rules of contest.

------------------------------------------------------------------------ 3)

...

Additionally, I have been asking some members of our team about the possibility of them taking a specific responsibility on the team to streamline our work.

Particular tasks will work much better then "take some", but that can be done only when we have list of tasks, like: * openSUSE release: ** distribution *** ?? ** marketing *** ?? ** ??

* openSUSE conference ** server artwork ** presentations, slides ** marketing ** ??

* openSUSE and upstream ** branding packages ** logos (we had such request while ago) ** ??

...

I have received mixed comments. Understandably, we all are short on time and artwork could take a lot of time to be done.

I mentioned that I have Flickr, and there 3 more people that are added as moderators. What I would need is another guy with enough time to be added as Admin. Group should live even if one is prevented to maintain it.

Next thing is to start work on a flow diagram for artwork team, from question (request) to having artwork delivered.

------------------------------------------------------------------------ 4)

...

I also got an interesting feedback question: 1. Should we use a bug tracker system to coordinate specific artwork requests? 2. If so, what should/could we use?

This can be opportunity to use and popularize openFATE http://features.opensuse.org OpenFATE has nice tagging feature, so we can put few official tags to have them all in one pile, like: * artwork (used for any artwork related feature) * 12.3 (version specific) * 14.1 (13.x; do we want number that many don't like, but on the other hand should we show superstition by skipping it) * boot (for artwork related to boot process) * etc, and with additional tags to create sublistings when needed. What I'm not sure does features.o.o allow search, or browsing, by multiple tags.

Bugzilla should be used only for defects, so that relevant developers can be included in a CC list. We should have list of people that are able to fix software defects, so that bugs are not left hanging for undefined amounts of time blocking other to work.

...

Right now we only have the ML or IRC to make informal requests.

What is formal and informal in open source :)

When you work on your time, it is up to you to make a decision. It is more about nature of request, that may involve product management, or some developers, that may need Bugzilla rating features to keep bug reports on their plate under control. Other then that any written question is formal and has to be answered.

What we can do to prevent few working on the same part and none on the other is to use some software that is tracking who took job and to know when it is done, but to do that we need list of parts, and light flow diagram for standard process like artwork for release to see dependencies. I'll try to sketch some on a public Google doc, so anyone with a link can jump in and edit.

------------------------------------------------------------------------ 5)

...

One last point. We have discussed with a few members on the need to make a formal artwork release schedule. It is pretty obvious that artwork is something to be done earlier than the release schedule but there is no specific time frame for us. How about we do a 6 month artwork release cycle? The distribution takes 8 months and at month 6 they should have a release candidate ready. Is this too long, too short. Please comment.

Here is problem with term "release cycle".

Release cycle can be only the same as distribution one, not shorter, but we can agree on having most of work done at month 4 of distro release cycle, to have all of artwork at month 6 when starts RC testing. What we can do is to keep few non-critical tweaks for the release day, so that some change and ahh moment is present even by people that tested all stages.

Also, nothing prevents us from starting on next release N+1 when we are done with N, which should happen for most us 2 moths before official release day.

-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org