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

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> *Date: *Friday, December 4, 2020 at 00:14
> *To: *GNAP Mailing List <[e-mail]>
> *Cc: *Fabien Imbault <[e-mail]>, Yaron Sheffer <
> [e-mail]>, Justin Richer <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[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
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>