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

Tom Jones <thomasclinganjones@gmail.com> Thu, 26 November 2020 00:26 UTC

Return-Path: <thomasclinganjones@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 262B03A0DCF for <txauth@ietfa.amsl.com>; Wed, 25 Nov 2020 16:26:52 -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 56H_M1eVDrbg for <txauth@ietfa.amsl.com>; Wed, 25 Nov 2020 16:26:50 -0800 (PST)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 026FE3A0B37 for <txauth@ietf.org>; Wed, 25 Nov 2020 16:26:49 -0800 (PST)
Received: by mail-oi1-x22a.google.com with SMTP id a130so355695oif.7 for <txauth@ietf.org>; Wed, 25 Nov 2020 16:26:49 -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=qowjnALXn47XqCllqTJrftZEGZfWKbrsUrZGFsMqVMo=; b=FlnWM5XVpDskwso6FbDefNFD0UwoZr+oSjP51sK7pedJw4tv07fpIK11KTWWptW9Ly XUsBo+3fuCYVwjiW8IaidIczmBoQr0anEy8jmvDZpkpmMSgLp1K8LzcfCHGnW5eoPtMr RQ+GOWVHitImrsTsl9I88qx6fi1vlxIeRS3JfniYnenBLN1AtH0pNTgQY960Q6E61MKW kZiBOQae7mY7U0y2395E4mVffyAYjvJ3xStxVkp3nPuyOOcjZ8+KuhS3PruuWlkGG8Rz XmTxy0y3rUl0mfDjNr9kK1cxD/HG7ZXhTWDhDaVGGOtVcg98tzDs6DzNRt61aVxniDpA vd5A==
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=qowjnALXn47XqCllqTJrftZEGZfWKbrsUrZGFsMqVMo=; b=d5ZeAckJM/ADlj2QLqxvi6vMYlLHjl99rSE3voqi+EeQqZIYHdClZFLPprdA47cKPZ VXnSE9LscJnz9GvyNyNz3aRm10S8KF5DcMHnkVZ+4+CAHYp5LNIL2lk3BuudLL8M8E3Q yR6chxfWLGe8HxgMosfHKz24lU+P/7pT+Nm1MdljHdiDF0DMHU3AXInvADSocaxiCKXT /J8i3uxsFKXCpUnTv0ldy1rQaiYC0B6divlkvL/MxcwBuuWLa59zNzdQ8qAhHA2ohlqX 1B2kJ9ao1e+pQ0Ru91wIKCBh/Jt3wQUxpXH7p50syZ8ERsl6qvGRbp+4q2gNlbqNuKfy rs6g==
X-Gm-Message-State: AOAM533tENmwt8ZXxnlJDxyu8SDwVdgcEDLxBU5ua4qLv1nsFOF+PHMB 8YIfaN9I4BNeY4sKkr1sxjbCDdaoJVFM9pH0o63KW1kXJK4=
X-Google-Smtp-Source: ABdhPJzwHO+znvez2NzmSMyBuQfs6RoNhpB2yGiSwOEEjDHLtrCv5WBqDmHpghjJ+kvEHYmh66NLqfgFo8quOrIB3ls=
X-Received: by 2002:aca:5291:: with SMTP id g139mr458666oib.63.1606350409253; Wed, 25 Nov 2020 16:26:49 -0800 (PST)
MIME-Version: 1.0
References: <CAGBSGjqi8FdQg6RS_tpbW-R1JzeWiwKnJ2ObVxwMOkAbHaaJ_Q@mail.gmail.com> <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com>
In-Reply-To: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Wed, 25 Nov 2020 16:26:38 -0800
Message-ID: <CAK2Cwb7YKMVxRZZd5T5z2f0jGY-dQepnWqJ+=E_ruLuH_gS+kg@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000087450e05b4f799e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/7i1K1R0s_61wtO8YWRHUqfsnTck>
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: Thu, 26 Nov 2020 00:26:52 -0000

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
>