Re: [GNAP] GNAP Editors' Use of GitHub Issues

Fabien Imbault <fabien.imbault@gmail.com> Sun, 06 December 2020 18:25 UTC

Return-Path: <fabien.imbault@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C163A090D for <txauth@ietfa.amsl.com>; Sun, 6 Dec 2020 10:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gCorcEht7wM7 for <txauth@ietfa.amsl.com>; Sun, 6 Dec 2020 10:25:52 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 06EC53A08FA for <txauth@ietf.org>; Sun, 6 Dec 2020 10:25:51 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id o8so11193546ioh.0 for <txauth@ietf.org>; Sun, 06 Dec 2020 10:25:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JBggsNVVSIZocYW+vN90W7kr/woRZUwOSrkB+MLlVwQ=; b=WxCXD7mvmI4jmuY0XVp76shmtgCIxCguQe3aMf3O5+d0zUiX1McGx/ON/AuDjWn7Gr l2EwDEiaQkUqwtj74EWffn+OiSJ9YSvUz3ESovw2s2vh0uPeY3fsNCQcV2XE4lrjm4U1 IntWiNPrjZZcLc/vdmZAo+YJCRzD90wfHWC/D7/rXlKhN6BTy2SkaVSDKxTBqe2Zkdv4 9AGn9y6IIkUr10xDLucnnJy/LHPIwBIkpqv5LmhR+JGiI1eQnpX9epjaLGp+xjBwng7G DvkMQuLX8Jxp6xsQi5koMaTwZduIVM+SdB8cRjuxe+prAbbr33V4SCQoLlyFJ61N2bPw A+0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JBggsNVVSIZocYW+vN90W7kr/woRZUwOSrkB+MLlVwQ=; b=ZBC6InYwBE+stjefaY5fdu0CqL5+qJy2gBerXI9FFmZaMi9zv6hGlLXr9/fGelTWZf 94A8oRvBQrNinm2+P/4Y1n3hvQKnlXkDUsd/YLa2gtKoDzLn/obJV4BJpfUWk3CZOAjR IHYfCc2zhLUv5xmcwd6Bk6dsitp007mrLpmjby+SSUgWvVV0ZyVis113Qu8O6fVY9I9V 2mpMpuO2srR7ajstIwLQnV+GpwYCcDC506r+G6FTUJXCLMvoNbYKLfZv4U2kuVYK2qQ3 97x18QKV5YjBp/wGfBoOfZT2PY5WQq93D1GuG+qqsa1NU/THjpmNqR7Ukp8/u8G4UHZc RUhw==
X-Gm-Message-State: AOAM5307mgQyAQTl235yFa5uxLWAy5eWFL3rS3WxMPKiYt3xQJTcAv7U sRqxQKbc2n18QXYB/ZQHyoMdvnoQ6xsLi9Kgg1Q=
X-Google-Smtp-Source: ABdhPJyibHXT+3kXKorJ5vPye0ttzWECdkEp1i9UIb1v5FneCGYXGXgIDhfxDBeT1pDlFgYAf3eQwHVmTlvOqOV/wC8=
X-Received: by 2002:a02:5148:: with SMTP id s69mr17158860jaa.8.1607279151014; Sun, 06 Dec 2020 10:25:51 -0800 (PST)
MIME-Version: 1.0
References: <CAGBSGjqi8FdQg6RS_tpbW-R1JzeWiwKnJ2ObVxwMOkAbHaaJ_Q@mail.gmail.com> <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> <CAK2Cwb7YKMVxRZZd5T5z2f0jGY-dQepnWqJ+=E_ruLuH_gS+kg@mail.gmail.com> <CAM8feuQv8AZ24zwN=xrf=2OHJ064ONu-nkfb7YvtCcZDLjxHgA@mail.gmail.com> <505DC510-2210-4097-AAFC-B321992555DA@mit.edu> <CAGBSGjqyrp581D7Zvq_PcxRmehHLWXsmHcY8iDYfgDVxx5Qi5Q@mail.gmail.com> <45958447-4336-4CB3-BB4C-36E948474390@gmail.com>
In-Reply-To: <45958447-4336-4CB3-BB4C-36E948474390@gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Sun, 6 Dec 2020 19:25:38 +0100
Message-ID: <CAM8feuSzQn_aQVj-VG1F0yBv4EUcP7yCu_NB0HnSVf_V2SUAEA@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000d9e4fb05b5cfd627"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/laFi_24IPEfqiSWx7VX8lbbxI9U>
Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Dec 2020 18:25:55 -0000

Hello Yaron

Yes we'll send a recap of all issues that need text.

In case no one stands up and provide a proposal, those issues will indeed
be closed.

Fabien

Le dim. 6 déc. 2020 à 18:17, Yaron Sheffer <yaronf.ietf@gmail.com> a écrit :

> Regarding issues being closed with “needs text”, I don’t think people are
> going to scour the closed issues looking for interesting stuff 😊. As I
> said in the past, nobody cares for closed issues.
>
>
>
> Instead, I suggest to take these issues to the list and ask people to
> provide text. If nobody does, say within a week, close the issue.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From: *Aaron Parecki <aaron@parecki.com>
> *Date: *Friday, December 4, 2020 at 00:14
> *To: *GNAP Mailing List <txauth@ietf.org>
> *Cc: *Fabien Imbault <fabien.imbault@gmail.com>om>, Yaron Sheffer <
> yaronf.ietf@gmail.com>gt;, Justin Richer <jricher@mit.edu>
> *Subject: *Re: [GNAP] GNAP Editors' Use of GitHub Issues
>
>
>
> Thanks for all the discussion around this so far. On our editors call
> yesterday we talked about the "Postponed" label and have a new solution
> that hopefully addresses the feedback from this discussion.
>
>
>
> The high-level goal with the "Postponed" label was to be able to triage
> issues quickly while also making it clear that closing an issue doesn't
> mean we are rejecting the topic of the issue. The "Postponed" label clearly
> didn't communicate that intent. We will delete the label and instead
> replace our use of it with both:
>
>
>
> * Leaving an issue open and adding it to a milestone for the next upcoming
> IETF meeting
>
> * Closing an issue and adding the "Needs Text" label
>
>
>
> Adding an issue to the milestone of the next meeting will give us a
> timeline for making sure we come back to that issue, avoiding leaving a lot
> of hanging issues open with no clear path to move forward. Closing an issue
> with the "Needs Text" label indicates that there is nothing concrete to do
> with the issue at the moment, but if someone would like to propose specific
> text, the issue can be re-opened and discussed further.
>
>
>
> Justin and Fabien, feel free to chime in to clarify if needed!
>
>
>
> - Aaron
>
>
>
>
>
> On Mon, Nov 30, 2020 at 9:29 AM Justin Richer <jricher@mit.edu> wrote:
>
> With the editor hat on:
>
>
>
> A new spec like this is exciting work, and it’s inevitably going to bring
> in lots of ideas of what it could do and what it could incorporate. These
> ideas are extremely valuable as they are what push new work into the realms
> of innovation and possibility and out of the status quo from which it
> sprang. But there’s a downside to this stream of ideas: most of them aren’t
> solid enough to incorporate in any way. They’re just loose ideas that maybe
> we want to consider, but they don’t have anything we can turn to and say
> “we should build that” or “we shouldn’t build that” since there isn’t any
> “that” to build.
>
>
>
> The editors have found that many of the issues currently filed seem to fit
> into this category. There might be an interesting idea in there, but
> without something specific to tie the idea to, we don’t have a lot to work
> with as editors, and there are a lot of other items that the group needs to
> decide and fix first. It’s an issue of triage.
>
>
>
> The goal of the “Postponed” tag, as I understand how we’re using it, is to
> tag issues that might need some future discussion, but we aren’t there yet.
> Something tagged as “Postponed” but left open long term was meant to flag
> it as an important detail we should get back to, when we can. Something
> tagged “Postponed” and closed was meant to flag it as something we might
> want to revisit, but only when we’ve got something concrete to work
> against. It’s not meant to say that the group has decided not to do it,
> it’s meant as a way to acknowledge the input and potentially tie back to it
> in the future, even if the issue got closed.
>
>
>
> It seems like the terminology of “Postponed” didn’t quite capture that
> intent, and honestly it might not be the best tool for us to use here. I
> think we we can work with the idea of IETF meeting-based milestones, as has
> been suggested by several people. The important outcome is that we don’t
> create a process that’s susceptible to getting buried in “wouldn’t it be
> nice if…” sentiments to the detriment of forward progress on a functioning
> protocol. Right now, we’ve got a lot of items that amount to possible
> future branches, and while we shouldn’t simple forget them, we shouldn’t be
> focusing energy on them until someone is able to take the effort to explore
> that branch. At such a time, we can open a new issue and PR’s for that, and
> link back to these historical artifacts for background and context. By
> tying such issues to an IETF meeting milestone, we can put some boundaries
> on items to keep them from languishing. When the milestone comes up, we can
> evaluate if there’s something to look at yet or not.
>
>
>
>  — Justin
>
>
>
> On Nov 27, 2020, at 4:03 AM, Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
>
>
> Hi there,
>
>
>
> One of the potential problems we'd like to avoid is to have an ever
> growing list of open issues that we never close.
>
>
>
> The idea of having milestones (e.g. IETF110) might be a complementary way
> of managing priorities.
>
>
>
> Editors will revert back to the list after the US vacation days.
>
>
>
> Cheers,
>
> Fabien
>
>
>
> On Thu, Nov 26, 2020 at 1:26 AM Tom Jones <thomasclinganjones@gmail.com>
> wrote:
>
> i agree - drop postponed - if you can't say till when, then close. Issues
> can always be added by anyone at anytime.
>
> Peace ..tom
>
>
>
>
>
> On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer <yaronf.ietf@gmail.com>
> wrote:
>
> Commenting on the proposed process (chair hat off):
>
>
>
> I think “postponed” issues should not be closed. Once something is closed,
> we should be reasonably confident that it is resolved for good. People
> rarely search through closed issues.
>
>
>
> Moreover, IMO the label “postponed” is not actionable. Instead, I suggest
> to mark such issues with future milestones, e.g. “IETF110”, meaning that at
> this time we will review the issue. Otherwise, the “postponed” issues will
> probably suffer the destiny of all “low priority” issues – they will be
> ignored for months and eventually closed en masse. See [1] for GitHub
> milestones.
>
>
>
> Otherwise I am fine with the rest of the process.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> [1]
> https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-milestones
>
>
>
>
>
> *From: *TXAuth <txauth-bounces@ietf.org> on behalf of Aaron Parecki <
> aaron@parecki.com>
> *Date: *Wednesday, November 25, 2020 at 18:37
> *To: *GNAP Mailing List <txauth@ietf.org>
> *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues
>
>
>
> The editors met yesterday to discuss the issues that were pulled out of
> the previous draft text and document a process for how to resolve these and
> future issues. We would like to explain how we plan on using labels on
> GitHub issues to keep track of discussions and keep things moving.
>
> When there are substantive issues or pull requests, the editors will avoid
> merging or closing those outright, and instead mark them as "pending", so
> that these can be brought to the attention of the larger group. If no
> additional discussion happens on these, the merge or close action will be
> taken in 7 days. Note for this first round we are setting the deadline for
> the issues below as Dec 11th due to the US holiday and the fact that this
> is the first time using this process.
>
> "Pending Merge"
> When specific text is proposed in a PR (by anyone, not limited to the
> editors), and the editors believe this text reflects the consensus of the
> working group, this marks that the PR will be merged in 7 days unless there
> is a clear alternative proposal accepted by the working group.
>
> "Pending Close"
> When the editors believe an issue no longer needs discussion, we'll mark
> it "Pending Close". The issue will be closed in 7 days unless someone
> brings new information to the discussion. This tag is not applied to issues
> that will be closed by a specific pull request.
>
> There are two additional labels we will use to flag issues to the group.
>
> "Needs Text"
> The editors suggest this issue needs additional text in the spec to
> clarify why this section is needed and under what circumstances. Without a
> concrete proposal of text to be included in the spec, this section will be
> removed in a future update.
>
> "Postponed"
> This issue can be reconsidered in the future with a more concrete
> discussion but is not targeted for immediate concrete changes to the spec
> text. When used on its own, this label does not indicate that an issue is
> targeted to be closed. An issue may also be marked "Pending Close", and
> this is used so that we can distinguish closed issues between discussions
> that have concluded or things that we may want to revisit in the future.
> Remember that closed issues are not deleted and their contents are still
> findable and readable, and that new issues can reference closed issues.
>
> With these labels in mind, here are the list of issues and their statuses
> we were able to discuss on our last editor's call. The action on these
> pending issues will be taken on Dec 11th to give the group enough time to
> review this list. For this first round, many of the issues are marked
> "Pending Close" as we're looking for low hanging fruit to prune the list of
> issues down. In the future, you can expect to see more "Pending Merge"
> issues as we're bringing proposed text to review by the WG.
>
> Postponed:
>
> * Generic claim extension mechanism
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131
>
> Pending Merge:
>
> * Make access token mandatory for continuation API calls
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129
>
> Postponed and Pending Close:
>
> * Fetchable Keys
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
> * Including OpenID Connect Claims
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
> * Application communication with back-end
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
> * Additional post-interaction protocols
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83
>
> Pending Close:
>
> * HTTP PUT vs POST for rotating access tokens
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
> * Use of hash with unique callback URL
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
> * Interaction considerations
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
> * Expanding dynamic reference handles
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76
> * Post interaction callback nonce
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73
> * Unique callback URIs
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
> * Instance identifier
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
> * Requesting resources by reference
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
> * Mapping resource references
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35
>
> ---
>
> Aaron Parecki
>
> https://aaronparecki.com
>
>
>
> -- TXAuth mailing list TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>