Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix)

Robert Sparks <rjsparks@nostrum.com> Mon, 28 September 2020 16:58 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8CD3A1009 for <tools-implementation@ietfa.amsl.com>; Mon, 28 Sep 2020 09:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level:
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwEL_S7sb5Yr for <tools-implementation@ietfa.amsl.com>; Mon, 28 Sep 2020 09:58:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90F63A1005 for <tools-implementation@ietf.org>; Mon, 28 Sep 2020 09:58:43 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08SGwdRI070840 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <tools-implementation@ietf.org>; Mon, 28 Sep 2020 11:58:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601312323; bh=FCYZOoLPfKIzZc4si6ZaDuIymB4aUa3rpVjsuw5dGA4=; h=Subject:To:References:From:Date:In-Reply-To; b=MERo7K6UoxRHb90rBdAjzEkvaClt47WuwESfz3txt1ofcUWnbj+Ko/fJPorO7gK/q a43iUYeNq2r1R4fhnPYtRUOx81stdHl4JivUgUu+7rAL9ldAZikzreRSHUIkgNNTlS E9HnZtaqQ+1c36YsB7L2uEnRJ/44Hr+FnJjvogII=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: tools-implementation@ietf.org
References: <ebcf4e32-99f3-5c70-a58a-6cabcd86095b@amsl.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <82db14a0-8518-b7cb-596b-3b0eb0af0346@nostrum.com>
Date: Mon, 28 Sep 2020 11:58:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <ebcf4e32-99f3-5c70-a58a-6cabcd86095b@amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-implementation/-XEtASA21P-XsFktXT5ioS4BDj8>
Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix)
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation <tools-implementation.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-implementation>, <mailto:tools-implementation-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-implementation/>
List-Post: <mailto:tools-implementation@ietf.org>
List-Help: <mailto:tools-implementation-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-implementation>, <mailto:tools-implementation-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2020 16:58:46 -0000

On 9/28/20 11:52 AM, Glen wrote:
> Hi team -
>
> Hope you all had a good week.
>
> I've read the announcement below, I have only one comment.  The 
> paragraph starting with "The secretariat is operating" seems 
> unnecessary from my point of view.  The current expectation/perception 
> of the community is that the secretariat operates the IETF's IT services.
The point of the sentence is to answer "why aren't we taking advantage 
of the offers other groups have made to host".
> That's what we're contracted to do, that is in fact my job.  In 
> addition, we already know that the community has privacy issues, so we 
> could assume that self-hosting is at least not an aversion point. 
> Therefore, the things stated in that paragraph are already the norm.
>
> I could expand on this if desired, but, to keep things brief, I'd 
> recommend removing that entire paragraph.
I think it is quite necessary.
> If we decide to go public-cloud later, we can and should open that as 
> a separate topic. For now, the paragraph says nothing new, and adds 
> unnecessary wording to the announcement.
>
> Other than that (and Robert's subsequent tweak) I have no further 
> thoughts right now!
>
> Also I saw the commentary about "glen@amsl.com" in the emails. When 
> running the initial install script, the script takes two parameters - 
> the server FQDN, and the server (human) administrator account.  I 
> provided my own email address as the first account to create, which is 
> where Zulip got this.
>
> This was unanticipated, but I guess something to "learn" through these 
> tests.  If we end up using Zulip in a permanent state, we will of 
> course know about this and choose a better address/account/alias for 
> this.  For now, I will look through and see if this can be safely 
> changed via a setting, as I have time.
>
> I note that the message doesn't *require* contact, but just *offers* 
> my address as a human contact point:
>
> >> Contact us any time at glen@amsl.com <mailto:glen@amsl.com> if you 
> run into trouble, have any feedback, or just want to chat!
>
> I don't think we should delay announcement until this can be changed; 
> I don't think for a test instance this is a big deal, but I will still 
> look, because I don't want those emails.  :-)   But I'm fine with 
> whatever you all decide.
>
> Glen
>
>
>> We are deploying trials of the matrix and zulip chat services to gain
>> operational experience and get community feedback about how well 
>> these services
>> meet the need for IETF related chat.
>>
>> We have clear evidence from the IETF 107 post-meeting survey
>> (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) 
>> that many
>> IETF participants find jabber a significant problem.  This is partly 
>> due to
>> difficulties in finding a free jabber service and partly due to client
>> issues.  There are two paths to try to resolve these problems, one is to
>> improve the IETF jabber service and the other is to switch to an 
>> alternative
>> groupchat solution.  The community has already taken a step on the 
>> latter
>> path with the introduction of an IETF Slack space, and we want to 
>> ensure that
>> this path is properly explored by widening the range of options to well
>> established free/open source tools.
>>
>> The installs currently have almost no local configuration or 
>> customization.
>> Over the next few weeks, we will be exploring reconfiguring them to use
>> datatracker credentials for sign-in, and explore bridging between these
>> systems, Slack, and Jabber. One consequence of these explorations is 
>> that
>> there will  likely be times, outside of meetings, when accounts will be
>> disrupted or even removed and will have to be recreated. Initially, we
>> suggest you use an email address for the username on each service.
>>
>> The secretariat is operating each instance. We've chosen this path 
>> for these
>> trials over third party hosting to learn what would be needed if the 
>> community
>> felt self-hosting was important in the longer term.
>>
>> The services can be found at matrix-trial1.ietf.org and 
>> zulip-trial1.ietf.org.
>>
>> Any matrix client can be used with the trial matrix server. There is 
>> also a
>> web client available at at matrix-trial1.ietf.org.
>>
>> Similarly any zulip client can be used with the trial zulip server, 
>> which has a
>> built in web interface.
>>
>> We would like feedback on how well each client meets chat needs during
>> meetings, both the full online IETF 109 meeting, virtuals, adhocs, and
>> hallway conversations.
>>
>> Around December, we will assess our experiences and the feedback 
>> received to
>> inform what chat services we provide in the future and how we will 
>> operate
>> them. In January, these trial instances will be taken down. We do not 
>> intend to
>> preserve or migrate any account configuration or chat history from 
>> the trial
>> instances as we move forward.
>>
>> This does add to the potentially confusing large number of places 
>> conversation
>> might take place. We hope to address that with some level of 
>> bridging, at least
>> with Jabber, but have been cautioned by the respective development 
>> communities
>> that bridging between Zulip and Matrix is unsatisfying since the 
>> conversation
>> models in the two applications are so different.
>>
>> The chat services are intended to be explorational and informal. 
>> However,
>> please treat them as contexts where contribution rules apply (See
>> https://www.ietf.org/about/note-well/).
>>
>> We are not, at this time, planning to host jabber accounts. We may 
>> revisit that
>> as an option as we continue to gather more feedback.
>>
>> Please send feedback on the services to tools-discuss@ietf.org
>