[Automated-testing] RFC - Automated Testing Summit proposal

[Neil Williams]

On Wed, 3 Oct 2018 at 01:21, Trevor Woerner <twoerner at gmail.com> wrote:

> Hi Tim and Neil,
>
> Thank you both for your input.
>
> I was *literally* hovering over the "Send" button to a reply to Neil's
> message when gmail notified me of Tim's response ;-)
>
> On Tue, Oct 2, 2018 at 7:13 PM <Tim.Bird at sony.com> wrote:
>
>> Several projects related to open-source software have invitation-only
>> summits, so I disagree that ATS sets any kind of precedent.
>>
>
> I wasn't trying to imply ATS is setting a precedent, quite the contrary, I
> am sad to see this as an increasing trend, and that nobody, apparently,
> seems bothered by this. Is this really a good thing? And where does it
> stop? If everyone agrees that the points raised for invite-only events
> outweigh the negatives, then what's to stop so many more open source
> projects from becoming invite-only? That can't possibly be good for the
> ecosystem.
>
> I single out ELC(E) specifically because (if I have my history correct)
> both it and this are Linux communities founded/lead/driven by the same
> person; that example wasn't random.
>
> Spending money to fly across the globe to attend such an event... or, even
> more amazingly, having my employer shell out these sorts of funds so I can
> physically attend such events (usually after much begging and sales
> pitches)... is such an *honour* and a *privilege*. I have both spent my own
> money to attend Linux conferences, and am so thoroughly grateful to every
> employer who has spent their money (either in full or in part) so I could
> attend these sorts of things. The money spent to attend these events isn't
> immaterial; at least not to me. The rare and privileged few of us who are
> actually able to do this is already a group so small and uniform. Let's
> face it, Linux conferences aren't exactly bastions of diversity (but
> hopefully that changes). It strikes me as quite the slap in the face to fly
> halfway across the globe, to find someone standing at the door saying
> "sorry, thanks for coming, but...". And if this trend is (as it appears to
> me) increasing, it doesn't bode well.
>
>
>> There are tradeoffs in benefits and costs between public and
>> private meetings.
>>
>
> True, I hadn't considered things from the money side. And I am grateful to
> those sponsoring these things since, I presume, the money collected by
> registrations probably doesn't cover everything. But co-located events
> sometimes carry additional costs to attend. It isn't ideal, but a modest
> fee isn't prohibitive.
>
>
>
>> I think it would be great to get a public conference set up, dedicated to
>> automated testing.
>>
>> This is what I could do this time.
>>
>
> Okay, valid points. And much thanks to you for your tireless efforts over
> the past many decades!
>
> However, I maintain that something feels fundamentally wrong with the
> notion of any open source project having invite-only events, and this trend
> shouldn't be encouraged. But worse yet, is that nobody else, apparently,
> finds this troubling. Or if they do, don't find it troubling enough to say
> anything.
>
> Or let's say this: please don't publicly announce invite-only open-source
> events!
>

I think that's unavoidable - specifically in this case but also for any
other large group.

The problem for us is that the group is just forming. In established
groups, individuals and teams self-identify who needs to attend smaller
gatherings and then announce what has been accomplished for discussion with
the full group. For this event, none of the members of any of the groups
were identifiable. The main role of the survey is to find out who is in the
full group - identifying sub-groups / teams would naturally fall out of the
survey analysis.

There does need to be discussion amongst the entire group once the initial
event has been completed. Invite-only events are only a problem where the
results are also kept only to attendees of the event or where results
cannot be discussed. There needs to be trust that the people invited are
invited for the right reasons and have enough information and knowledge to
make some decisions on behalf of the entire group. Such delegation needs to
be set up and itself be open to discussion.

Without some form of delegation, large open source projects cannot
function, for precisely the reasons of cost and complexity already covered.
Meetings between those delegated to perform their delegated roles should be
invite-only and publicly announced. The results of the meetings then also
need to be announced to the entire group and discussed in the open.

"There will be a meeting of the N team composing of people delegated to
these roles (X) to discuss Y on date Z. A report will be made to mailing
list B for discussion."

The problem for this group is that the membership of the group isn't clear
let alone teams, delegation or governance.

However, we're getting very much off thread.



> --
> _______________________________________________
> automated-testing mailing list
> automated-testing at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/automated-testing
>


-- 

Neil Williams
=============
neil.williams at linaro.org
http://www.linux.codehelp.co.uk/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/automated-testing/attachments/20181003/e5cef280/attachment-0001.html>