On Mon, Jan 9, 2017, at 03:28 PM, Josh Boyer wrote: > On Mon, Jan 9, 2017 at 8:56 AM, Brian Exelbierd <bex@xxxxxxxxx> wrote: > > On Mon, Jan 9, 2017, at 01:53 PM, Josh Boyer wrote: > >> On Mon, Jan 9, 2017 at 6:07 AM, Brian Exelbierd <bex@xxxxxxxxx> wrote: > >> > Warning: This email is long. I don't know how to avoid that. I debated > >> > making this a wiki, but I think we need more discussion that just > >> > editing. There is no tl;dr. If you want a tl;dr perhaps you should > >> > wait a while and participate near the end of the conversation. > >> > > >> > Warning: The opening text is the same for both Part I and Part II. > >> > > >> > During 2016 I had the privilege of helping to plan and execute Flock and > >> > attended both FUDCon LATAM (Puno) and FUDCon APAC (Phnom Penh). Talking > >> > to people has led to me to believe that these events may not be meeting > >> > all of our goals. Specifically we are spending a lot of time and money > >> > on them and may not be getting our full value. I also heard a lot of > >> > comments about how the events are not equal from people who thought they > >> > should be and not well distributed across the world from people who > >> > thought they should be. This led me to believe that there is a lot of > >> > confusion about why we do these events and what we want out of them. > >> > > >> > Since it is easier to edit than to create, I am going to propose some > >> > ideas. My goal is less to present this as a polished proposal ready for > >> > a vote and more to allow us to have a discussion around the finer points > >> > of the events strategy. It would be nice to see this discussion come to > >> > an end by the end of March so that it can have impact this year. The > >> > planning for Flock will begin soon (see my another of my emails today) > >> > but the FUDCon processes are not heavily started, as far as I can tell. > >> > > >> > Additionally, while history is important, I think it is equally > >> > important that we consider what we want to accomplish today and in the > >> > next few years, not just what we tried to accomplish in the past. > >> > Therefore I've written this without too much reference to what is being > >> > changed and instead as an idea of what we should be doing. I look > >> > forward to folks bringing forward suggestions for continuing activities > >> > from the past or better incorporating lessons learned that I may have > >> > missed. > >> > > >> > I look forward to your feedback and input. > >> > > >> > regards, > >> > > >> > bex > >> > > >> > # Flock > >> > > >> > Flock is described by most people to me as the "Fedora Contributor > >> > Conference." Therefore, I'd like to see us put together a structure to > >> > continue to make that statement more and more accurate. If we are going > >> > to have a contributor conference, I think we need to understand why > >> > having one is important. I have been told that we need Flock for these > >> > reason (I am sure I am missing some): > >> > > >> > ## Goals > >> > > >> > * Increased Contributor Bonding - Contributors should meet each other in > >> > person and strengthen their relationships. We are a far-flung remote > >> > community and at times we forget about the person behind the FAS ID. > >> > Fedora works best when we work together. > >> > > >> > * Increased Project Cohesion - The Fedora Project is a huge complex set > >> > of moving pieces and fantastic people. At times it can be hard to know > >> > or remember what is going on and what we are working on. Flock should > >> > provide a touchstone to keep all parts of the project interconnected. > >> > > >> > * Presentation and Discussion of Large Ideas - Some ideas just aren't > >> > well served by a wiki page and an email thread. When we make major > >> > changes (think rings or editions) we need to talk them over. We need > >> > presentations and forums for face to face discussions. > >> > > >> > * Work - Yes, this is what FADs are for, but we can save money and time > >> > if we schedule work sessions in a place where we are already going to > >> > have the right people present (see more later). Flock has been > >> > described by several people as needing to be more of a "do conference" > >> > instead of a "talk conference." I agree that if we are having a > >> > *contributor* conference we should focus on *contribution.* > >> > > >> > * Cross-pollination - Having contributors from all over the project in > >> > one place creates the opportunity for a fantastic hallway track > >> > (informal, unplanned conversations and working groups). Problems being > >> > solved in one area may be the answer for problems being discovered in > >> > another. We may find out that we have multiple groups working on the > >> > same problem in different ways and that working together may help (or > >> > conversely allowing them to have a compare/contrast session may help). > >> > > >> > ## Programming > >> > > >> > Moving Flock more toward a "do" conference means that we should change > >> > the way we develop the program. Specifically, I believe that we should > >> > ask people why their talk and workshop proposals should be included in > >> > greater detail. > >> > >> Can you describe what greater detail means? We already have people > >> submit abstracts, and those tend to be fairly detailed. > > > > I was not on the programming committee last year so this may already be > > covered. I included it as a point that I think we need to ensure we > > have in the future. I did attend a few talks that didn't seem to have a > > reason to be at Flock last year. I also got similar feedback from > > others, so I wanted to emphasize this point. > > I would be curious to know which talks those were. > > >> > ### Theme > >> > > >> > I believe the council should, with community input, set some themes for > >> > each Flock. These themes are not absolutes, but instead should be one > >> > of the many factors considered when looking at programming submissions. > >> > This way we can also help keep Flock focused on doing. > >> > >> We did this last year. It didn't really pan out well. Whether that's > >> because of the themes that were set or something else, I have no idea. > > > > I think that our themes here need to be the strategic goals of the > > project. If we decide we want to be the first green Linux Distribution > > (whatever that means) then a theme for Flock might be "how to become a > > green distribution." This way we know what we are trying to focus on in > > addition to other priorities. > > > > What were the themes last year? > > Strategic goals of the project based on the existing Council Objectives. > > Like I said, it didn't pan out well. That's not saying it's wrong, > but that in practice people want to talk about what they're working > on. That doesn't always fit with strategic longer term goals that > come from "top down". While the council may choose to set some goals directly, I believe most of the goals should be reflections on the thoughts of our community members. Therefore these shouldn't be a top-down goals in most cases. I think it is great for people to talk about what they are working on. I would like those talks to be held elsewhere when appropriate so that we can draw in new contributors as well. Some of them are going to be great for Flock, others not so much. > >> > ### Talks > >> > > >> > Talks will always be part of Flock, however, we can ask a few more > >> > questions to help the committee choose them. > > >> > 2. If this talk is about a specific piece of software or technology, why > >> > is presenting it at Flock better than presenting it as a Fedora-inspired > >> > talk at another conference? > >> > 3. What actions will you be taking as a result of the feedback you > >> > receive on this talk? What actions are you looking for your audience to > >> > take? > >> > >> That implies they get feedback... other than in-room/after-talk > >> feedback from attendees, we don't have anything in place to help them > >> there. Adding that might be helpful, but it isn't simple. > > > > I would like to see evidence that the presenter is thinking about how > > this talk will influence the future. In some cases the talk is just to > > convey information. In others it is more. I'd like to see the speakers > > think about this. > > OK, that's fine. I interpreted feedback as an after-the-talk input. > > >> > ### Workshops/HackFests/etc. > >> > > >> > We need more focused work and planning sessions. However, for them to > >> > >> I'm not really sure I agree with that. The workshops I've seen have > >> been very focused and a lot of work is actually getting done at them. > >> The Fedora Infra team is particularly good at this. > > > > I don't understand. You want our workshops to be less focused? > > No, I was saying I disagreed with your insinuation that they weren't > already focused. I am sorry I wasn't clearer in the introduction. I deliberately did not set out to suggest changes and instead just described a vision. We may already be doing some of this and I definitely want that to continue. However, I deliberately didn't set out to write a critique of what we are doing, positive or negative. > >> > ## Funded Attendance and Costs > >> > > >> > I was told by several people that they felt like most non-EMEA and > >> > non-NA contributors were not encouraged to attend Flock. Several people > >> > related stories about how they had been told that because their region > >> > had a FUDCon they should attend that instead. This sentiment was > >> > usually relayed to me during a conversation about funded attendance. I > >> > want to address this through our structure. > >> > >> This is accurate. Because LATAM and APAC have FUDCons and NA/EMEA do > >> not, we have prioritized contributors from NA/EMEA for funding. > >> HOWEVER, we have always funded travel for people outside of those > >> regions at every Flock. Priority does not mean exclusion. > > > > Having done some of the work, I know what you say is true. I also know > > that non-EMEA/NA folks have pointedly said that they felt like priority > > was exclusion in a lot of cases. This is a communication issue we can > > fix. However, I don't think we should be equating FUDCons and Flock > > unless we plan to actually make them equal. > > We aren't equating Flock and FUDCons. That's why we bring in > contributors from non-EMEA/NA regions to Flock whenever we can. > However, the existence of FUDCons in those regions while they are not > a thing in NA/EMEA means there IS disparity in conference options > between the regions. I have tried to address FUDCons in the other email. I think that the disparity creates a feeling of second-class citizenship for those who don't have a contributor conference in their region. It also creates the inverse feeling regarding user conferences for NA/EMEA. > >> > ### Tickets > >> > > >> > Flock has expenses that are not necessarily part of the "funding" of a > >> > funded attendance. This could be meeting room costs or the costs or a > >> > group lunch or evening activity. Some of these costs are fixed for the > >> > event (e.g. Meeting room rental) and some are per attendee (e.g. Evening > >> > activities). Therefore I think we should set a ticket price equal to > >> > the cost of all per attendee costs. This means that a ticket will cover > >> > the cost of these items, and not make a profit. > >> > > >> > However, not everyone should have to pay for their ticket. I believe we > >> > should adopt a strategy similar to OpenStack. OpenStack provides free > >> > admissions for all active contributors. We should define contributor > >> > activity and provide a similar benefit. Defining an active contributor > >> > is hard, but we can probably start with something like "generated X > >> > fedmsg events in the last year" or "acknowledged as a contributor by a > >> > subproject." I think it needs to be more than "cla+1" but flexible > >> > enough to account for work that may not be commit oriented. > >> > > >> > If only active contributors attend Flock then no tickets will actually > >> > be sold. This is OK. However, non-contributors who attend will pay the > >> > costs of their attendance. This may help those folks understand that > >> > there are better Fedora events for them to attend. This should also > >> > reduce the issue with no-show non-contributors. It won't help with > >> > no-show contributors[0]. I also believe it is reasonable to have a > >> > refund policy in place for those with a documented reason for not > >> > showing up (illness, etc.). I think we can solve this by adopting a > >> > policy like many other events of offering refund schedules, etc. This > >> > should not be a heavy process and it should actually not be a huge > >> > burden. > >> > >> We can do this but I'm not sure it will make a material difference. > >> It also discourages walk-ins, which we tend to to actually be between > >> 40 and 80 people. > > > > there is nothing that prevents us from doing ticket funding at the door > > for active contributors who are walk-ins. > > Walk-ins are very very rarely existing contributors. The purpose of > walk-ins isn't to bring in late-show contributors. It's the one > non-contributor focused aspect of Flock, in that we encourage people > to come because we already have the space, etc. It's the one growth > aspect of Flock, which may or may not lead to the NEXT set of > contributors. > > I'd suggest we leave walk-ins as "attend the sessions, but you don't > get food or events". We can do that, however, I believe that our programming should be very heavily contributor focused. That may limit the appear to walk-ins. If we need Flock to serve a different purpose we should program that in from the start. regards, bex _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx
