= Problem =
This problem was originally identified in [https://fedorahosted.org/marketing-team/ticket/200 Marketing Trac Ticket #200].
The problem is that there are many resources produced by Marketing or other sub-projects each release that Ambassadors will find useful for advocacy at events and in areas in their regions. The resources are also great tools to enable passionate users to spread the word about Fedora on their own if they find the resources and create / print them.
However, these resources are scattered and not organized. There is not "one place to look" to find these things. To find the resources, you might need to travel from wiki page to wiki page, mailing list to mailing list, Trac to Trac, etc. It can be tedious, frustrating, and ultimately holds back the productivity of our Ambassadors.
= Analysis =
The idea originally proposed in the Marketing Trac was having a way to centralize the existing resources in one place where any Ambassador, user, or Fedoran can look to find the resources they need to learn "what's hot" or "what's new" in Fedora. The resources could be images for stickers, printable PDFs for brochures, CD sleeve artwork for install media, and any other useful resources.
Centralizing these resources will make them more accessible for everyone and improve organization for creating these resources.
= Enhancement recommendation =
== Phase 1: Listing content ==
The first step for this ticket is coming up with a list of either existing or desired resources that need to be brought together. Any existing artwork images, brochures, templates, etc. that can be considered an Ambassador "resource" or "tool" should be listed so we know '''what to find''' and '''where to look'''.
This list can be compiled in bulletpoint format in this ticket. The Ambassadors list should be notified about this ticket to drop in feedback about what some of these resources may be and where they are hiding.
== Phase 2: Combining them together ==
Where to host these resources is the next big question. With the advent of Pagure, this seems like the best place to do so. It's a git-based forge that many other areas of the project are already using.
The repo should be created by the Fedora Marketing group in Pagure (if Pagure is the agreed way to host this data). The repo should be managed by Marketing members. Ideally, the repo should be organized by content that is specific to each release and general content that is applicable for any release.
Feedback, ideas, and questions welcome.
The original idea was to create an set of very simple, but usable by every ambassador and mentor - marketing set, without the hassle. But then, if I examine this problem in bigger picture - noticed that basically we don't have proper background wide sharing system, that can form groups (or teams, or as we call this idea as "Fedora Hubs"), and keep our contributors work, communications, and connections together. I think we also missing proper integration to our desktops. In individual pieces and tools (pagure, git, mailing lists, irc, mote, fedmesg, and many more) we have everything to be an complete great infra system, but somehow maybe we missed the point. In order to solve this, I suggest to try to insert an Owncloud/Cloud to get a backbone of our services. Owncloud has already great plugins, and not only usable to sharing, else you can have mailing, syncing (so we can avoid outdated things), webdav for file access, and perhaps we can bind within it many-many more things.
Within Owncloud apps, you can have already mailing, news, polls, calendar too. To see more, why this can be great - there was an Linux Action Show part, where calendar and webdav are demonstrated: https://www.youtube.com/watch?v=HkEf1b1s56E (from 54:10 - Gnome integration, online accounts - where you are already able to sync calendar, contacts, documents and files -> so if this can be integrated with Fedocal, FAS people IRC and Fedmesg, Hubs docs, and Files (owncloud sync client to fedorapeople host, as a dropbox appliance), and in future perhaps events....)
WebDav demo (from 55:50-) where if you map certain folders and files towards our contributors, you can keep sync files, direct access, direct editing - and possibly no more search within mailing lists, through wikis, and tickets.
I know this can be way too much, but I feel that we can solve many more productivity issues with this - and maybe this worthy for an another ticket in target of F26 or F27.
First, I realize I forgot to thank you, Zoltán, for adding your thoughts and ideas about this to the ticket. I realize it's been six weeks since you've heard a response, thank you for being patient. We have this one on our agenda now and we had a lot of awesome discussion and brainstorming happen at our last meeting.
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting/2016-05-31/commops.2016-05-31-15.56.html 2016-05-31 meeting].'''
Hey all, apologies for being late to post the discussion and feedback from our meeting to this ticket.
In today's meeting, we discussed the two phases mentioned originally in the ticket and the best way to go about centralizing these resources. Obviously one of the biggest hurdles for this ticket is going to be tracking down all of the different places where these files leave and bringing them together. But before we can really start doing that effectively, we should have a game plan for how we're going to implement this.
= Note about ownCloud =
I think the thoughts and ideas mentioned about ownCloud as a possibility is interesting, but based on feedback from package maintainers and Infrastructure team members, the possibility of hosting this within Fedora's infrastructure presents many problems and challenges. To implement a Fedora ownCloud doesn't seem like the best approach to doing this in my eyes in light of the incoming Fedora Hubs.
I think Hubs will be able to implement and showcase many of the ideas you mentioned about centralizing resources in a single place. In a sense, Hubs is a Fedora-customized version of the ideas you had for ownCloud for how it ties everything together from all different places, like Fedocal, Pagure, IRC, mailing lists, and so much more. A lot of these integrations have been made possible by advancements on the fedmsg bus, and as it continues to grow, more and more things are added to it. The inclusion of mailing lists and Bugzilla in fedmsg were recent and major milestones for helping provide the framework and tools for having the level of customization and centralization of information and tools that Hubs will be able to offer.
= An index =
One of the ideas we discussed in the meeting is having a git repository that serves as an index or "pointer" for all of the different files and resources that exist in the grand web of Fedora. Think of it was a repository with ordered, hierarchical directories that would have README files in each folder. So you might navigate to design/marketing/brochures/python/ to find the files for the "Fedora <3 Python" brochures that were created recently.
Questions to ask on this idea:
= A single repository =
The other idea would be to host a single repository where all the files actually live for this one. If this method were approached, it might even be possible to create a package for anyone to easily install "fedora-assets" or something similar. Ultimately, though, this would have the advantage of having all of the assets in a single place and not having to worry if they were deleted somewhere else.
= Reaching out =
We wanted to reach out to the Design Team to get a feel for their thoughts and ideas on these suggestions before moving forward. I will send out an email to their list with this ticket comment shortly.
In today's hack session (still happening now in #fedora-meeting-3!), decause dropped a few links to some example repos of projects that are "indexes" of sorts, which might be an example of what we want to achieve here, pending the feedback, thoughts, and opinions of the Design Team.
Hi, organizing our assets was Maria's project and she set up a repo for this here:
But we really request ambassadors open up a design ticket or at least talk to a designer before using any of these materials.
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting/2016-06-07/commops.2016-06-07-15.58.html 2016-06-07 meeting].'''
= Reconsidering the approach =
First, big thanks to mizmo and gnokii for offering their feedback on the list and in the meeting today. From this feedback, I think it would be a good idea for us to reconsider our approach on how we resolve this issue.
Based on the feedback received, it's a ''strong'' wish for Ambassadors to first reach out to the Design Team in a timely manner to request artwork or the necessary files for sending to printing / production companies. With this in mind, we thought the best way to go about targeting this ticket might be reconsidering how we '''communicate this information to Ambassadors'''. It seems like the process is unclear for Ambassadors, and it definitely differs from region to region.
= Design Team Headaches =
To help add some background into devising a solution, mizmo gave us a great list of some of the pains / headaches from a Design Team perspective. Resolving some of these issues would help make the Design Team more efficient and make their ticket queue easier to process if resolved.
= New solutions =
One thing I would like to see happen with this ticket is tight integration with regional leaders (treasurers, storytellers, and logisticians) on communicating this information with their regions. Two of these three roles were created this fiscal year, and were added to help handle a variety of different tasks within Ambassador regions.
The Logisticians, for example, would be useful to loop into this conversation so they know how to advise Ambassadors on the process for requesting art assets, getting specific assets for print / production, and the timeline for when this should be done. The treasurers would be useful to link into this conversation to help manage the list of vendors used across the Project, which would help simplify the work for the Design Team. The Storytellers can work with their region to make sure that requested assets from the Design Team are advancing the "story of Fedora", promoting the Project, and helping grow the presence of free and open source software at events in their respective regions.
= What do you think? =
I'd like to get some feedback on this ticket based on the above ideas and crafting a solution that is in the best interest of both the Design Team and the Ambassadors. In my eyes, the next step would be to begin drafting a wiki page outlining the official procedure for how an Ambassador can request assets and what is expected and what isn't.
It will be important to consider regional differences in this ticket, which could present a problem farther down the road. I would like to involve regional leaders in this ticket as soon as we have a draft of the process that is approved by Design Team members.
What are some other member's thoughts on this?
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting/2016-06-14/commops.2016-06-14-15.58.html 2016-06-14 meeting].'''
In the meeting, we discussed a little bit about why having a body like FOSCo to coordinate between the teams would be a good and useful idea. I was going to add that perspective into this ticket, but after sitting in on yesterday's FAmSCo meeting, I added the observation to the [https://fedorahosted.org/famsco/ticket/373#comment:23 FOSCo proposal ticket]. You can read more on there about why something like FOSCo will be important to have in Fedora.
I just posted to the [https://email@example.com/message/QSU5V4ALJFAYRFMQB4RQ365UQRMOECCV/ Design Team mailing list] (and CC'd CommOps) about the wiki page deliverable for this milestone.
You can find the proposed draft for the communication process between Ambassadors and the Design team [https://fedoraproject.org/wiki/Ambassadors/Design here].
Any comments and feedback welcome! Once a +1 is received from the Design Team, we can work on socializing this information with regional delegates, the Ambassadors mailing list, and possibly a Community Blog article.
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting/2016-07-05/commops.2016-07-05-15.56.html 2016-07-05 meeting].'''
Mostly updated the team on the above information. Still awaiting feedback from the Design Team, although mizmo is on PTO right now, so might be a bit before hearing back. Once we get the +1 from some Design Team members, we can work on shipping and socializing this page out.
My ideas for socializing it were:
Community Blog article communicating it
Posting to Ambassador mailing list about the updated process
* Directly contacting all regional storytellers and treasurers about the guidelines and communicating it with their region
I'm going to tentatively mark this ticket as "completed"!
= What happened and how =
I had a brief 1x1 with mizmo today to check in on the guidelines on the wiki. After a small revision, she approved of the content. Since then, the following things have been done:
= Solving the original problem =
I think this groundwork will help improve communication about the design process to Ambassadors in the short-term. This should help improve the accessibility of assets for Ambassadors and also simplify the review and handling of requests by the Design Team. Ultimately, the concern of having access to resources (which was agreed to be problematic for regional printing issues) should be alleviated by keeping communication lines open between both teams.
It is worth mentioning that this was intentionally '''short-term'''. The big idea is that this info or guidelines would be more accessible in Hubs and be able to help actually take Ambassadors through the steps in some form. However, I think this is definitely more long-term (although definitely realistic). I think the work done in this ticket should make it easier for revisiting farther down the line with Hubs – after all, the information and process has to start from somewhere.
I feel confident that this should help resolve the concerns in the original ticket. But I am happy to hear from others if they believe this is not the case.
to comment on this ticket.