Rescheduling regular DMB meeting day/time

[Dan Streetman]

On Tue, Nov 9, 2021 at 11:47 AM Rafael David Tinoco
<rafaeldtinoco at gmail.com> wrote:
>
>
> With the intention of this thread being to come up with days/times
> that will allow the most number of board members to attend, I propose
> we eliminate the "alternating time" meetings and just stick to a
> single day/time that works best for the board. That also implies that
> we're placing additional burden on candidates who don't normally
> overlap with whatever time slot we choose, meaning we should make the
> board more available to by-request meeting times and/or mailing list
> applications.
>
>
> I'm mostly lurking these days, but I want to say that this last part is
> critical to get right.  The DMB is a super important part of the pathway
> that new developers take when getting involved in the community, and
> it's really critical that you don't end up favouring people who are for
> whatever reason able to be available when you all are. (Most obviously
> by living in similar timezones to enough DMB members.) If you're going
> to end up pushing them to asynchronous meetings then this needs to be
> made a proper first class option, in documentation and the actual
> candidate experience (timely, good quality interactions as you get on
> IRC).
>
> To this end, I want to throw this option out: for maximum fairness when
> there is only one meeting slot provided, consider moving *all*
> applications to the same asynchronous method and keep the meetings only
> for administrative DMB matters which you feel need to be discussed
> synchronously.
>
>
> I completely agree, with one addition - I think candidates should have
> the option of requesting a synchronous meeting if they want one.
>
>
> I'm +1 on defaulting to async and letting the applicant to choose if
> he would like the process to be sync. Only one thing we have to consider:
> async "tests" are easy to "pass" as you can seek for information on a
> question done by e-mail for example (while the sync interviewing process
> does not give that option to the candidate).

In some of the applications we've had, I have suspected that
applicants who have 'teams' supporting them (i.e. not candidates from
the community) might have more experienced people privately 'helping'
them with the answers to our questions. Now, I don't actually think
that is a *bad* thing; we aren't trying to administer a closed-book
school test here, and no actual engineer would ever make an important
decision they were unsure of without consulting peers. However, I feel
it's unfair to community candidates who may be 'on their own' going
through this process. And I have no direct knowledge or proof, so
maybe it's only my suspicion and not actually happening.

> Nevertheless, I'm not a
> huge fan of the interview process we currently have as it always seem
> to me we're trying to trick candidates to answer something wrong. I
> prefer to analyze the previous work of the candidate and base my
> vote from this "async" root of information anyway.
>

And I think this is the real core of the issue - I'm in total
agreement that we should be reviewing candidates on their actual work,
not on answers to realtime questions. If all their work looks very
good, I don't need to ask them anything.