Rescheduling regular DMB meeting day/time

[Rafael David Tinoco]

>> 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 realise that this is a widely supported view, but I'm opposed to this.
> In recent meetings I've been -1 a number of times because I think it has
> become evident in a meeting that an applicant is not ready in a way that
> wasn't obvious from their written application.
> 
> Usually these are social rather than technical things, such as a lack of
> understanding of who is in charge of what. I consider this kind of thing
> *more* important than technical ability, because when people know who to
> ask and understand how we make decisions, then everything else can be
> figured out by talking to people.

That is exactly where we are diverging in our votes, lately. IMHO the
process shouldn't be tied to "who is in charge", but in "how capable and
trustful this applicant is".

Also, our processes shouldn't rely in a specific person. I'd rather give
+1 to an applicant that does not know "who to look for" quite well, but
has done incredible DEV or SRU work (as we've had lately). 

I also think that we should encourage applicants to use devel mailing
list more often whenever doubts on "what to do" appear INSTEAD of trying
to make sure they won't have doubts because they already know how
everything works (specially for applicants from outside Canonical, which
are quite few and we should seek more).

PS: I'm not saying we should accept anyone just because they're
technically good.

> I think a realtime discussion is the best way to assess this kind of
> thing. I remain open to compromising on this on a case-by-case basis
> when it is necessary, but I see it as a compromise, not the norm.