Re: [UG-ADMINS] OpenCFP but....smaller?

Hi Beth!

I agree with 1-3 and 6 of your speaker points. Strongly on 1 & 2. On 3 I
see your point but  can only sympathize.


And all 3 of your organizer points.

As for 4-5. Honestly, at a developer conference, I don't want a developer
speaking that can't operate github. :) I say that as politely as I can but
git is an essential skill in our industry...and github is pretty simple.
(and I suck at git, but can still get stuff done)

5 I can see...maybe. But I didn't take it as that kind of sensitive
information would be part of the public submission.

Cheers!
=C=


On Mon, Feb 23, 2015 at 6:40 PM, Beth Tucker Long <[email protected]>
wrote:

> A few thoughts.
>
> From a speaker point of view:
>
> 1. I think this adds a lot of pressure to an already stressful CfP process.
>
> 2. I feel this benefits the more popular speakers who can get their
> followers to comment positively on their talks whereas a newer speaker
> would not be able to pull as much public commentary (similar to how
> speakers ask their Twitter followers to vote for their Confoo talks).
>
> 3. As a female speaker who has issues with inappropriate comments being
> left in feedback after my talks, I wonder if this would just be another
> venue for people to leave inappropriate comments about me publicly or for
> people to judge me by my minority status instead of by my talk and
> qualifications.
>
> 4. I think requiring Git usage to submit a talk would exclude people who
> don't know how to use it, and to be honest, it is not an easy system to
> just pick up if you are not at all familiar with how it works.
>
> 5. There may be privacy issues with speakers who do not want people to
> know what their application contains (like a request for reimbursement
> because they can't afford it, location of their home airport, etc.)
>
> 6. May negatively impact speakers if conferences can see that they have
> submitted to a conflicting or rival conference.
>
> From a conference organizer point of view:
>
> 1. There are often more things that need to be accounted for besides
> audience interest in a topic. For instance, it may be a topic the audience
> needs to be exposed to even if they aren't initially interested. It may be
> a necessary talk because of budget constraints on speaker travel. This
> system doesn't leave much room for that.
>
> 2. I can imagine this would lead to lots of whining/criticisms/accusations
> about how one speaker got more votes but didn't get in, etc.
>
> 3. Makes it more difficult to integrate into your website as you'd have to
> import the data from Git, and the data is not being constrained in how it
> is formatted, so there may be no standardization in the formatting.
>
> Cheers,
> Beth
>
> Beth Tucker Long
> Treeline Design, LLC
> 807 Arbor Vitae Place
> Verona, WI 53593
> 608-770-6677
> http://www.TreelineDesign.com
>
> > On Feb 23, 2015, at 22:08, Evan Coury <[email protected]> wrote:
> >
> > Out of curiosity, how would folks feel about an actual conference doing
> > something like this? Is there a consensus on how *speakers* feel about
> more
> > open/public CFP processes? I imagine attendees will typically appreciate
> > the transparency.
> >
> >
> > On Mon, Feb 23, 2015 at 1:51 PM, Kristopher <[email protected]>
> > wrote:
> >
> >> I like this idea. Instead of issues, you can have them open a Pull
> Request
> >> to have their talk added to the "Talks" page. Accept their PR if you
> want
> >> them to talk, close it if you don't want them to. People can comment and
> >> give feedback.
> >>
> >>
> >> On Mon, Feb 23, 2015 at 3:49 PM, Jonathan Sundquist <
> [email protected]>
> >> wrote:
> >>
> >>> You could also use github and have people log issues.  Then you can
> allow
> >>> people comment on them if they thing its a good talk or not.
> >>
>
> --
> Usergroup Coordination Mailing List (http://ug.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
*Culture of Respect <http://bit.ly/1tOIyjG>*
How to find, hire, and retain developers