[Standards] 2017-11-29 XMPP Council Meeting Minutes

Jonas Wielicki jonas at wielicki.name
Thu Dec 7 08:27:59 UTC 2017

On Donnerstag, 7. Dezember 2017 08:14:48 CET Kevin Smith wrote:
> On 7 Dec 2017, at 08:03, Jonas Wielicki <jonas at wielicki.name> wrote:
> > On Mittwoch, 6. Dezember 2017 17:03:16 CET Kevin Smith wrote:
> >>> On 6 Dec 2017, at 16:39, Sam Whited <sam at samwhited.com> wrote:
> >>> 
> >>> On Wed, Dec 6, 2017, at 10:34, Kevin Smith wrote:
> >>>> The motivation in xep1 is that the outgoing Council members might have
> >>>> not given public feedback, due to being on Council, but that they could
> >>>> have feedback that should be taken into account. For the sake of two
> >>>> weeks, I’m not sure it’s worth shortcutting giving that opportunity
> >>>> here.
> >>> 
> >>> I don't think the two weeks matters necessarily but everyone on the
> >>> council now was previously a member and could have given feedback. If
> >>> they didn't then, I don't see why being on the council would make a
> >>> difference.
> >> 
> >> It’s the opposite case that xep1 is concerned with. A Council member
> >> might
> >> decide not to give feedback on standards@, knowing that they can give
> >> such
> >> feedback when voting, and such when they’re not on Council their
> >> not-yet-voiced comments might fail to be heard.
> > 
> > FWIW, in a first and second iteration of thought, I think we should try to
> > change the relevant passage of XEP-0001.
> > 
> > It encourages council members (and to say this to begin with: I doubt that
> > anyone from current or previous council actually did that, at least not
> > with malicious intent) to delay their feedback until the voting process,
> > at which point the community has no way to reasonably address that
> > feedback (be it negative or positive) with remarks which may have been
> > overlooked and taken for granted (thus not mentioned) by others.
> > 
> > This could invoke a feeling of "not being heard" in the community, which I
> > think could be very detrimental.
> > 
> > So encouraging that behaviour by means of XEP-0001, I think we should not.
> > 
> > Looking forward to the third iteration of thought :-) (i.e. what you
> > think).
> I think not re-issuing LC actually has the opposite effect, and reduces
> public feedback.
> Take this case, for instance. I am newly on Council, so I didn’t review this
> XEP thoroughly as part of the LC, now I have reviewed it more thorougly and
> I have feedback, so there are two possible outcomes:

I originally focused on "outbound" council members, as per your statement. I 
also did not consider that council members do a more in-depth review as part 
of their role, and that people who run for council but aren’t elected yet may 
not have the time or motivation to do that review during the LC in the 
previous councils term.

> 1) The LC is reissued and I send out my Council feedback publicly in
> response to the LC. There’s a clear path to addressing feedback. 
> 2) The LC
> isn’t reissued, it goes straight to vote and I just -1 in the Council
> meeting.
> There’s the additional risk that if the LC isn’t reissued that new Council
> members feel pressured to just +1 and not do their jobs reviewing XEPs that
> came up before the previous Council because of a sense of completing
> previous Council’s work. I’d have thought avoiding the potential for
> Council to feel pressured to not do their job is worth keeping this text in
> xep1 for.

Okay. I’d like to point out that your argumentation has shifted from "it is 
for 'outgoing' council members to be able to voice their feedback from their 
thorough council-duty review" to "it is for 'inbound' council members to have 
some time to properly review it, to do their duty as council". This isn’t 
important, because I think your points are solid.

Thanks for clarifying.

Still I would assume that council members (being at the end of their term or 
not) raise their feedback on-list in time so that it can be addressed by the 
community (as has happened in your example).

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171207/21cb2f96/attachment-0001.sig>

More information about the Standards mailing list