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

[Tom Jones <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> on behalf of Aaron Parecki <
> [e-mail]>
> *Date: *Wednesday, November 25, 2020 at 18:37
> *To: *GNAP Mailing List <[e-mail]>
> *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 [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>