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

From: Justin Richer <[email-masked]>
Date: Wed, 2 Dec 2020 15:10:12 -0500

The editors met again today to process some more of the outstanding issues. The following issues have been added to the queue for pending close with the same Dec 11th deadline as the first set (that’s next Friday). Editors’ comments are included on GitHub.

Pending Close:

* JWS Headers for JOSE-based signature methods
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/106
* Key redundancy in DPoP method
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111
* Fragility of JOSE-based signature methods
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/108
* Detached-JWS Header, 
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/107
* Create more examples of interaction modes
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/52
* Splitting the “claims” request
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/63
* Response Extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/80
* Provide guidance for defining new interactions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/61
* Guidance for Grant Request Extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/65
* Privacy considerations of returned user information
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/74
* Alignment with RAR
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/34
* Non-role protocol elements
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/33

Needs Text:
* Updating and reading access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99

The editors believe that this list list now includes all of the issues filed that represent items that are mostly just comments on the state or history of the protocol as extracted from Editor’s Notes, as discussed in #128.

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/128

The goal of this exercise, as stated in #128, is to clean out the clutter of the issue backlog and allow us to focus on specification text, issues, and features. Note that for these marked issues, closing the issue is not an indication that a final decision has been made to exclude a feature or option. However the editors determined that the issues as written did not incorporate actionable text or sufficient use cases to move forward at this time. If future discussions wish to raise any of these issues again, particularly additional features, they can do so with more explicit context and a concrete way forward, and link back to these historical items.

Additionally, several of these were determined to be part of larger discussions, and so separate issues have been raised to incorporate them:

* Terminology
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29
* Security considerations
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/135
* Guidance for extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/134
* Privacy considerations
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133
* Claim extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Note that other issues are also being processed in addition to this clean-up effort, so please keep an eye out for pull requests and discussions on those. Also please note that if you :support: a change in a pull request, it’s helpful to the group if you comment as such, or leave an “approved” review using the GitHub issue tracker.

Finally, the editors are working on a proposed update to the use of the “proposed” tag based on working group feedback, and we’ll update shortly with those details.

Thank you,
 — Justin, Aaron, and Fabien

> On Nov 25, 2020, at 11:36 AM, Aaron Parecki <[email-masked]> wrote:
> 
> 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 <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 <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 <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 <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 <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 <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 <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 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84>
> * Interaction considerations
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 <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 <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 <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 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55>
> * Instance identifier
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 <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 <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 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35>
> 
> ---
> Aaron Parecki
> https://aaronparecki.com <https://aaronparecki.com/>
> 
> -- 
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 3 Dec 2020 14:14:26 -0800

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 <[email-masked]> 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 <[email-masked]>
> 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 <[email-masked]>
> 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 <[email-masked]>
>> 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 <[email-masked]> on behalf of Aaron Parecki <
>>> [email-masked]>
>>> *Date: *Wednesday, November 25, 2020 at 18:37
>>> *To: *GNAP Mailing List <[email-masked]>
>>> *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.
>>>
>>> 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:
>>>
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129
>>>
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83
>>>
>>> Pending Close:
>>>
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76
>>> ** 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
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
>>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35
>>>
>>> ---
>>>
>>> Aaron Parecki
>>>
>>> https://aaronparecki.com
>>>
>>>
>>>
>>> -- TXAuth mailing list [email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 06 Dec 2020 19:16:59 +0200

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 <[email-masked]>
Date: Friday, December 4, 2020 at 00:14
To: GNAP Mailing List <[email-masked]>
Cc: Fabien Imbault <[email-masked]>, Yaron Sheffer <[email-masked]>, Justin Richer <[email-masked]>
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

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. 

- Aaron

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 <[email-masked]> 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.

Cheers,

Fabien

On Thu, Nov 26, 2020 at 1:26 AM Tom Jones <[email-masked]> 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 <[email-masked]> wrote:

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.

Thanks,

                Yaron

[1] https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-milestones

From: TXAuth <[email-masked]> on behalf of Aaron Parecki <[email-masked]>
Date: Wednesday, November 25, 2020 at 18:37
To: GNAP Mailing List <[email-masked]>
Subject: [GNAP] GNAP Editors' Use of GitHub Issues

"Pending Merge"

"Pending Close"

"Needs Text"

"Postponed"

Postponed:

Pending Merge:

* Fetchable Keys

Pending Close:

---

Aaron Parecki

https://aaronparecki.com

-- TXAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 6 Dec 2020 19:25:38 +0100

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 <[email-masked]> 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 <[email-masked]>
> *Date: *Friday, December 4, 2020 at 00:14
> *Cc: *Fabien Imbault <[email-masked]>, Yaron Sheffer <
> [email-masked]>, Justin Richer <[email-masked]>
> *Subject: *Re: [GNAP] GNAP Editors' Use of GitHub Issues
>
>
>
> 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.
>
>
>
> 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"
> 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:
>