On Fri, Mar 30, 2012 at 10:05 AM, Tom Callaway <tcallawa@xxxxxxxxxx> wrote: > On 03/30/2012 02:03 AM, inode0 wrote: >> Can we just say we had a communication failure and move forward? I >> appreciate the substance of your reply today. It is very helpful and >> provides a basis from which to work productively toward a solution. > > Agreed. I think part of why we drafted around "Ambassadors-only" was > specifically because we could not identify a better subset of > contributors that should have these permissions. I also suspect strongly > that the very act of being interested in producing non-software Fedora > branded goods for giveaways probably qualifies them to be Ambassadors. ;) Let me give you one real example. The person who did the original work creating the case badges everyone loves and that we have ordered multiple times is not an ambassador. But he volunteered to do the work under the supervision of FAmNA, specifically with me walking him through the steps we follow. He had a vendor he had already used in other projects who produced very high quality case badges so was ideally suited to help us in this one small area. I don't think he had any interest in going through a rather lengthy mentoring process required to join the ambassadors group just to contribute in this one way. He offered to do this for us as a thank you for our help working with him organizing a new community open source conference in New Mexico which sadly didn't work out in the end. Because I think his contribution was immensely valuable I want to avoid setting ourselves up in some way that we lose out on opportunities like that one. Five years ago joining the ambassadors group was very easy, basically just ask. Today it is far more involved as we mentor each new applicant before they are allowed to join the group for various reasons that don't really matter in this context. >>> > * We need to have a measure of quality control over the vendors that we >>> > use to produce the goods. This simplified down to: We shouldn't be using >>> > vendors who provide a poor quality product or who are otherwise >>> > extremely hostile to deal with. We also can assume that all vendors are >>> > good until proven otherwise. Lastly, we can assume that Ambassadors are >>> > the best people to let us (Red Hat and Fedora) know when a vendor is >>> > "bad" and should not be used. The practical expectation here is that >>> > most (if not all) vendors will never be flagged as "bad", and that will >>> > only be necessary in extreme cases. >> I really have no problem with the above. In fact, we have mostly kept >> track of vendors we have used and we do note vendors we've had >> experiences with that were problematic. That falls into the >> institutional knowledge sort of thing now though as we don't document >> it. We haven't advertised which vendors we don't intend to use again >> in public and that is my only objection to the wiki Good Vendor/Bad >> Vendor section. I don't mind reporting bad vendors to you or to Red >> Hat or to the Fedora Project. Institutional knowledge only goes so far >> and it would be better to document the problems we have with vendors >> and I'm comfortable doing that in a non-public way. > > Well, okay. The problem with the "non-public" way is that there is no > good way for other Ambassadors to know when a vendor shouldn't be used, > unless we require all Ambassadors to pre-clear their vendor with the > keeper of the "bad list". If this list was managed on a page where Red > Hat explicitly took responsibility for the content, would that be > acceptable? Ambassadors in my experience don't just go off and make swag now. They bring their ideas to a group like FAmNA and normally first find out if we would be willing to fund producing the item. The funding approval mechanism serves us well in several ways. We, FAmNA for example, work with the ambassador as he works through the process and can and do impart information about vendors. It is possible that something might slip through and a vendor we had a previous bad experience with might be used again. I don't recall that happening but it could. Aside from being a potential target from an offended vendor another reason I dislike the public list so much is that what will happen is that if we have a single initial bad experience with a vendor we are going to toss them overboard. It may be a great vendor and we just were the unlucky 1 in 10,000 customers who had a bad experience. I don't want to tar such a vendor in public without much more knowledge about the vendor than what we will have from one experience using them. The good list bothers me a little too because it seems like a public endorsement of vendors we either haven't used or of vendors we normally only have slight experience using. If we will need to authenticate against FAS to get designs would it be that much bother to do the same to review/modify the vendor lists so we don't appear to be openly endorsing or belittling vendors? >>> > * We need to not have a blank check on the sort of items that can be >>> > produced. For example, it would almost certainly be unacceptable for the >>> > Fedora logo to be used on a condom. We can't effectively generate a >>> > blacklist of all of the items that would not be acceptable, so we chose >>> > to generate a whitelist instead. If there are items missing from the >>> > whitelist, please let us know. The fact that the whitelist contains >>> > items that have not been widely produced (or perhaps not at all) is a >>> > reflection of our effort to try to be as extensive as possible. >> The suggestion that we might make condoms with a Fedora Logo on them >> doesn't make me feel trusted. Just as a blacklist can't include every >> preposterous item no whitelist can include every reasonable item. My >> preference would be that you say this group has demonstrated good >> judgment in selecting merchandise types for the past five years and we >> will trust their continued good judgment until such time as they screw >> up. If that can't happen and if the process of adding one is simply >> dropping you note asking you to add "usb sticks" to the list then I'm >> fine with doing that too. How or what is involved in getting a new >> type approved was not specified in the draft beyond getting approval >> from Fedora Legal by following some process that would be linked to >> later so I had no way to know what that process might entail. > > I used the condom example specifically for a few reasons: > > * Someone actually proposed it at Red Hat a few years ago and went so > far as to generate a mock advertisement. > * I wanted to point out something that the vast majority of sensible > humans would agree is not in the best interest of the Fedora name, but > something that is at least possible that some ambassador somewhere might > someday think is okay. I can say with certainty that there are ambassadors who I know who think items we would reject out of hand would be fun to make. This is another place that the funding approval mechanism comes in as a safeguard. There are enough sensible ambassadors in FAmNA and I'm sure in the other funding decision points (FAmSCo and the rest) to prevent such items from ever being approved or produced. > The process for amending the whitelist should be extremely > straightforward. In fact, it probably makes sense to separate the > whitelist from the TM guidelines. Another goal in the TM guidelines was > to try to keep it as static as possible, and have it refer to separate > pages relating to process or lists that could be dynamic. This is also > why <LINK> appears all over the place. (My previous draft had it all > pulled in, but we agreed that separating the dynamic items makes sense.) > > I describe the "add new type to whitelist" process below, but the plan > was to use trac for this to ensure they do not get lost. > > Last, but not least, usb keys should definitely be on the whitelist, so > I've already amended the draft for that. > >> I'm not really sure how well this will work for me. I'm not against >> trying it but honestly as someone not very inclined to producing my >> own designs I normally show up with an idea and a template from a >> vendor and ask Mo to make it happen for me. I'm not sure I could wade >> through piles of variously formatted designs and be successful finding >> what I would need. Maybe it can be cleverly organized so even I can >> find stuff though. > > That same process would still be valid, it would just be considered a > "new design", and at the end of its creation, it would be added to the > list. Mo has been working on a layout where the previously approved > designs are presented visually in a gallery or table setup. Each > pre-approved design would be given a number for quick and easy > identification. Basically, think of it as a catalog of stuff that > ambassadors can look through, then if they see a design they like, they > can click the corresponding link, and it will prompt them to FAS auth. > When they FAS auth, it will check for success and that the user is in > the Ambassador group, then let them download the high quality > preformatted design files to give to the vendor to make it into a > t-shirt or a sticker or whatever. > >> If Fedora Community members or Fedora contributors is too broad I >> don't know if I have a suggestion. Even the ambassador group is very >> broad when compared to the small number of ambassadors who have done >> this work. Aside from a different FAS group I don't really have a >> suggestion for capturing the subset of the community who contributes >> in this way. > > I don't necessarily have a problem with creating a different FAS group > for this, but everyone involved in this process (me, mo, robyn, pam) all > agreed that we trust the entire Fedora Ambassador group with this > responsibility, so there is no need to limit it further or create some > sort of separate vetting process. While I trust the entire Fedora Ambassador group I don't necessary trust every individual member of that group. With the additional safeguards provided by funding decisions I'm comfortable with that but as funding authority is becoming more distributed those safeguards also become less effective. And a separate group that is easy to add members to from other groups like our friend who made the case badges for us appeals to me. I'm happy to let people think about this some, maybe there are other solutions. John _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
