Revert some changes made in transfers.txt transfer_type=4 and 5 proposal

[bdferris-v2]

In #303, the spec was updated to include functionality for in-seat trip-to-trip transfers via the addition of two new values 4 and 5 for transfer_type in transfers.txt.

This PR proposes two changes, one large and one small:

1. (Large) Drop transfer_type=5 from the spec. In the original PR discussion Add trip-to-trip transfers with in-seat option #303, there were two feed providers who utilized transfer_type=4 but there was never a producer who utilized transfer_type=5. Per the spec guiding principles, speculative features are discouraged. I acknowledge the potential use-case for transfer_type=5 but I'm not sure it's been fully proven out. I'd be willing to keep 5 as a reserved value if we think there is someone actively working on this.

2. (Small) Revert the change that made from_stop_id and to_stop_id conditionally required. After discussions with the original change authors (link), it became clear that the intention was that stop id fields are still required, but that they just shouldn't refer to a station for the in-seat transfer types.

See the related discussion from the #gtfs Slack channel and also in MobilityData/gtfs-validator#1266.

Announcement in https://groups.google.com/g/gtfs-changes/c/kF-HUR-L-kU/m/NJ8Vm6yJAQAJ

[skinkie]

There is real world data for transfer_type=4 and transfer_type=5 so I don't see what the problem is. If only a producer is the problem here I'll check what we can do.

[gcamp]

@skinkie when do you think you could have a feed produced?

I agree the functionality is important and making sure we have a producer is probably simpler than reverting and re-adding later.

[bdferris-v2]

Then let me ask some follow-up questions. Ultimately, my question is "Why do we need transfer_type=5?"

Start with a feed that isn't publishing block_id information, so no legacy in-seat transfer detection is possible. For this feed, transfer_type=4 is useful for indicating where in-seat transfers are possible, but it's not clear to me that transfer_type=5 has any use because in-seat transfers are off by default, so there is nothing to disable.

For a feed that is publishing block_id information, the story is more complex. As an example, MBTA is publishing both block_ids and transfer_type=4. Critically, they aren't publishing transfer_type=5. The implication is that if transfer_type=4 info is provided in the feed, then block_id-based in-seat transfers are disabled. Again, in-seat transfers are now off by default, so there is nothing to disable.

So when would transfer_type=5 be used? Maybe there is a feed that wants to provide block_id info but does not support in-seat transfers of any kind. How would they indicate that? Explicitly disable every trip linked by a block transfer? Seems excessive and potentially error prone. Is it enough to specify a single trip pair with transfer_type=5 and suddenly block_id-based in-seat transfers are disabled for the entire feed?

This gets me to the semantics of the following language in the spec:

If both a linked trips transfer and a block_id are provided and they produce conflicting results,
then the linked trips transfer shall be used.

What is the scope of that override? If there is a single transfer_type=4|5 in a feed, does that disable block_id-based in-seat transfers for the entire feed? Just for trips linked by the block in question?

[gcamp]

Ultimately, my question is "Why do we need transfer_type=5?"

I think the initial message of #303 explains it well. transfer_type=5 indicates that two trips are operated by the same vehicle, but riders cannot continue.

On your feed example questions, the general message to me is that block_id and transfer_type=5 can provide the same information. Feeds could provide both trip transfers and block_id or only one of them.

But trip to trip transfers provide the information in a clearer and less error-prone way (see the last two sections of #303). We can disagree on those points but being a different way of providing the same information it not a bad thing per se. See how fares v1 and v2 are co-existing.

What is the scope of that override?

The goal of that paragraph was to overwrite a single linked-trip but I can see how it can be miss-interpreted. We can change it.

[bdferris-v2]

I don't mind transfer_type=4 and block_ids co-existing. I'm just trying to be precise about how transfer_type=5 is supposed to work. And to that point:

The goal of that paragraph was to overwrite a single linked-trip

Is that how you've actually implemented it on your side? Was that the understanding of feed providers as well?

Coming back to MBTA's currently published feed, they are only specifying transfer_type=4. Should my interpretation be that because they did not specify transfer_type=5 for all other trip-pairs linked by block_id, then I should use the original block_id semantics for deciding if the remaining pairs should or should not be in-seat transfers? My guess would be that this is not the intent of MBTA, but that they intended I only allow in-seat transfers for trip-pairs explicitly listed with transfer_type=4.

[gcamp]

I think you need to define what is the "original block_id semantics". My understanding is that the current use of block_id is solely to share links between trips at the vehicle level and nothing about in-seat transfers. At least, that's what the spec is saying.

With that in mind my interpretation of "use the original block_id semantics" and "I only allow in-seat transfers for trip-pairs explicitly listed with transfer_type=4" are equivalent.

In real-world usage where consumers have heuristics about block_id and wether they mean to be in-seat or not, I think it's safe to assume that if a feed contains transfer_type=4 then no implicit in-seat transfer should be created. However I don't think that's something we can fix in the spec without fixing block_id and how it's defined.

Unfortunately, since both use-case of block_id are actively used I'm not sure this is fixable. Maybe this is more of a best practices problem? transfer_type=4/5 was our take on the it.

[bdferris-v2]

I think you need to define what is the "original block_id semantics". My understanding is that the current use of block_id is solely to share links between trips at the vehicle level and nothing about in-seat transfers. At least, that's what the spec is saying.

I’ll forgive your alleged innocence :) because we both know the spec has plenty of ambiguities and gaps big enough to drive buses through. block_id-based in-seat transfers is one of them and has been since day-1 of the spec, when it was added to support in-seat transfers for the founding GTFS agencies. Google has tried to be up-front in our interpretation (docs, docs), but I’ll acknowledge that in never made it into the official spec and probably wouldn’t have gotten a consensus vote if we had tried (even amongst Google staff, for that matter). But ultimately, we wouldn't be here if these heuristics didn't exist. It's the whole point of #303.

In real-world usage where consumers have heuristics about block_id and wether they mean to be in-seat or not, I think it's safe to assume that if a feed contains transfer_type=4 then no implicit in-seat transfer should be created. However I don't think that's something we can fix in the spec without fixing block_id and how it's defined.

There is no safety in “safe to assume”. If we think it’s reasonable to say that “if a feed contains transfer_type=4 then no implicit in-seat transfer should be created for any trip” (and I do think it’s reasonable), then let’s say that. Is there anything stopping us? It certainly seems to be the intention of the MBTA, for example, though maybe should confirm with @losvedir? Or @hannesj as a different producer?

[hannesj]

There is no safety in “safe to assume”. If we think it’s reasonable to say that “if a feed contains transfer_type=4 then no implicit in-seat transfer should be created for any trip” (and I do think it’s reasonable), then let’s say that. Is there anything stopping us? It certainly seems to be the intention of the MBTA, for example, though maybe should confirm with @losvedir? Or @hannesj as a different producer?

I think this would be a reasonable change in the specification.

[leonardehrenfried]

I acknowledge that it's quite hard to undo years of doing things a certain way, but would not be the right thing to nudge producers into providing explicit transfers of type 4 rather than relying on block_ids?

I know, I know, I'm asking for a lot but at least we can add a bit of language to the spec in that respect.

However, I also think that it's reasonable to say that a single transfer of type=4 will disable the implicit in-seat transfers created by block_ids.

[paulswartz]

MBTA never considers block_id to create an in-seat transfer, and filters out the block_id field when providing data to Google for this reason. Our public feed does contain block_id and transfer_type=4 transfers, so we're happy to have clarity that this means no other in-seat transfers should be created.

[bdferris-v2]

Ok, now we are getting somewhere.

I proposed the following text:

If the trips associated with an agency include any linked trip in-seat transfers, as specified via transfer_type=4, then no implicit in-seat transfers should be created using block_id-based heuristics for any trips associated with that agency.

You'll notice I took the liberty of scoping the override behavior at the agency level, as opposed to the feed level. Selfishly, I would like a mechanism where if I need to merge two feeds, one which uses transfer_type=4 and one that does not, I can limit the scope of the behavior change. However, I acknowledge there may be other ways of accomplishing that.

But now back to my original question: why do we need transfer_type=5?

Running through the scenarios again:

• An agency that does not include block_ids but does use transfer_type=4 has no need for transfer_type=5 because the default behavior is to not create an in-seat transfer unless explicitly enabled with transfer_type=4.
• An agency that DOES include block_ids along with transfer_type=4 still has no need for transfer_type=5 because the presence of a single transfer_type=4 entry will cause all block_id-based in-seat transfers to be disabled, meaning there is no need to explicitly disable an in-seat transfer via transfer_type=5.

So what about an agency that wants to include block_ids but has no valid in-seat transfers anywhere in their network? How do they indicate they don't want block_id-based in-seat transfer heuristics? I'll concede they could use transfer_type=5 to annotate some or all linked trip pairs in their feed to effectively forbid the heuristic logic. But that seems kind of a roundabout way of doing it.

Instead, I'd propose a new field in agency.txt:

Field Name	Type	Presence	Description
in_seat_transfer_policy	Enum	Optional	0 or blank - in-seat transfers may be inferred by consumers from block_id-based trip linkages for trips belonging to this agency, where appropriate. 1 - in-seat transfers are only allowed where explicitly modeled by a transfer_type=4 entry in transfers.txt for trips belonging to this agency. If any trips belonging to this agency are annotated with a transfer_type=4, then the agency should be considered to have an in_seat_transfer_policy=1, regardless of the value specified here.

This approach has the advantage that it's more explicit about the intention of the behavior and it doesn't need to be updated as trips and blocks change.

I'm putting this forward as a hypothetical proposal that doesn't necessarily need to be included in this PR. But I keep coming back to my original question: why do we need transfer_type=5? Before you rush off to start producing feeds with this value, I ask if it's still needed (especially given the changes to the text around default behavior for transfer_type=4 proposed above). Is there some use-case I'm missing?

[gcamp]

I'm ok with the proposed change in principle. However I'd argue that

• that the change should be on the feed level and not agency level simply because I know producers will be confused by that behaviour (not a strong opinion).
• if we add that mention, we also need to change the block_id definition to mention heuristics-based definition. Having to define that without defining a rule is showing how flawed block_id is.

But now back to my original question: why do we need transfer_type=5?

An agency could want to provide operational level information of vehicle operating multiple trips without including any block_id because as we discussed multiple time, using block_id is full of pitfalls.

[bdferris-v2]

An agency could want to provide operational level information of vehicle operating multiple trips without including any block_id because as we discussed multiple time, using block_id is full of pitfalls.

How would they use transfer_type=5 in that scenario?

[gcamp]

from_trip_id=A,to_trip_id=B,transfer_type=5: Same vehicle but you must disembark per agency policy

Very simply, the agency will add trip to trip transfer with transfer_type=5 to convey those two trips are operated by the same vehicle.

From the spec :

5 - In-seat transfers are not allowed between sequential trips. The passenger must alight from the vehicle and re-board.

and

The trips linked together MUST be operated by the same vehicle.

I feel this might be better discussed in a call if you prefer, I feel we're going in circles.

[bdferris-v2]

Apologies, you are right, I was hung up on the in-seat transfer behavior and forgetting the goal to model trip connectivity more generally.

Do you think we met the bar for adding transfer_type=5 to the spec? There were no producers of this data. As a consumer, do you imagine any use for transfer_type=5 beyond real-time propagation?

[hannesj]

So what about an agency that wants to include block_ids but has no valid in-seat transfers anywhere in their network? How do they indicate they don't want block_id-based in-seat transfer heuristics? I'll concede they could use transfer_type=5 to annotate some or all linked trip pairs in their feed to effectively forbid the heuristic logic. But that seems kind of a roundabout way of doing it.

My assumption was that an agency which has both block_ids and in-seat transfers for most of their blocks, could signal with this transfer_type=5, that a in-seat transfer should not be created for some trips which share a block_id, but can be done for the others.

[gcamp]

Do you think we met the bar for adding transfer_type=5 to the spec? There were no producers of this data.

No indeed, I would work first on making sure there's no consumer wanting to produce this before reverting.

As a consumer, do you imagine any use for transfer_type=5 beyond real-time propagation?

No, that's the main use-case.

[bdferris-v2]

Do you think it's going to be necessary to have a producer both provide data with transfer_type=5 and have corresponding real-time data to justify inclusion?

Again, apologies for my mental hang-up on transfer_type=4/5 as being about in-seat transfers only, but my suspicion is that there will be plenty of agencies who are ok continuing to provide block_ids for the purpose of real-time delay propagation because block ids are what their CAD AVL system already produces. As such, I always thought of transfer_type=4 about fixing in-seat transfers first and foremost.

I acknowledge that even for same-vehicle trip continuation (ignoring in-seat transfers), block_ids are underspecified in the spec and you are attempting to fix that with transfer_type=5. But I'll admit I'm curious how many feeds will truly move away from block ids entirely.

[hannesj]

Do you think it's going to be necessary to have a producer both provide data with transfer_type=5 and have corresponding real-time data to justify inclusion?

I have no objection to removing it, as long as there is not anybody producing such data.

[leonardehrenfried]

Removing type=5 would make the OTP implementation a lot simpler as well. Even simpler if we agree that a feed with type 4 automatically disables block based in-seat transfers.

[gcamp]

Do you think it's going to be necessary to have a producer both provide data with transfer_type=5 and have corresponding real-time data to justify inclusion?

Not sure what you mean. If we consume transfer_type=5 and take it into account into our real time backend, wouldn't that be enough?

But I'll admit I'm curious how many feeds will truly move away from block ids entirely.

Yes, use of linked trips transfer is not going to be a quick transition and block_id will be with us for a while. Same as fares v1, but probably even more so since the problem is not as visible.

I'm surprised @hannesj and @leonardehrenfried want to move away from type 5. The number of time we had to explain this crazy rule to agencies, the number of feeds with invalid block_id, and the fact that each consumer needs to have their own implementation of logic to reconstruct trip links to warrants a better solution. Yes, in-seats transfers were the lowest hanging feature needed, but it doesn't change that block_id is flawed for both in-seat and vehicle continuation.

We're checking with producers that told us they were interested in type 5 in the past and will update here after.

[hannesj]

I'm surprised @hannesj and @leonardehrenfried want to move away from type 5.

It is not that I want to move away from it, I just think its inclusion in the standard might have been premature, as no producer for such datasets exist yet.

[bdferris-v2]

Bumping this for the new year. @gcamp any progress on identifying transfer_type=5 feed provider? @skinkie any updates on your end? If we are close, I'm willing to hold of on the transfer_type=5 change but if we still think it's going to be a while, I might try to move this proposal forward as-is.

[bdferris-v2]

Ok, not hearing any news on the transfer_type=5 front, I'm going to call for a vote and see where we stand.

Please vote with a +1 (for) or -1 (against) in the comments. Voting ends on 2023-01-26 at 23:59:59 UTC.

[mgilligan]

Sorry for the late comment on this thread, I was on an extended personal leave.

TriMet has plans to provide trip-to-trip transfers in our GTFS using both transfer_type 4 & 5. I plan to provide transfer_type=5 to avoid any ambiguity. I should have to space to work on this in a few months, with a target completion date in April.

[bdferris-v2]

What are your thoughts on this @mgilligan? April is far enough away that I'm still inclined to revert transfer_type=5 for now and come back to it when you've got a working implementation and verified there were no gotchas.

[skinkie]

0; I am not against removing it (simplicity) and also not against keeping it (completeness). OpenGeo

[mgilligan]

@bdferris-v2, I do not have a strong feeling either way. As @skinkie said, I like the completeness of having both types but if there is no strong opinion by consumers, I will just provide transfer_type=4 in my initial implementation.

So, my vote is 0 (zero)

[gcamp]

I was also still waiting on @BodoMinea who mentioned they were producing those types of transfers in #303 but could not confirm if it was type=5.

To me it fells silly to revert for a few months, considering there's multiple working implementation (OTP and us), an open source tool that produces the data, and interest in more producer to create the data. Our bad on not double checking type=5, we'll be better about it next time.

I'll vote 0 too, considering the conflict of interest here.

[isabelle-dr]

I have left comments in line to recommend 2 editorial modifications to this PR.

• a typo fix
• adding an explicit mention that stops's location_type other than stations or stops are forbidden for the from_stop_it and to_stop_id fields

[isabelle-dr]

Can we update Refering -> Referring and forbiden -> forbidden

[isabelle-dr]

I think we should explicitly mention, in both from_stop_id and to_stop_id:
Stops with location_type values 2 (Entrance/Exit), 3 (Generic Node), or 4 (Boarding Area) are forbidden.
This would justify the presence of the validator rule transfer_with_invalid_stop_location_type.

[isabelle-dr]

Same here: Refering -> Referring and forbiden -> forbidden

[brodyFlannigan]

Transcollines intends on starting the production of transfer_type = 5 in the next few weeks. Please take this into consideration.

I'll abstain from voting due to a conflict of interest (I am employed by Transit App and Transcollines, and myself and other Transit app colleagues discussed this issue earlier today which resulted in @gcamp voting 0. Because of this, I feel voting would be in violation of the "1 vote per stakeholder" rule as Transit App has already voted)

[bdferris-v2]

Noting the general ambivalence in the voting thus far :) I'll just restate that my main concern was less about the ideal of transfer_type=5 (though I remain somewhat ambivalent) and more about process. Ultimately, if folks are coming with data sooner rather than later, then I'm willing to withdraw the transfer_type=5.

But I'd still like to get in the "--Conditionally-- Required" and scope definition changes.

I'm happy to let this vote go a few more days to see if there is any more feedback, but ultimately, I can try again with a revised PR.

[leonardehrenfried]

Re: type=5

I would be in favour of removing it if we add some language to the effect of "if a transfer of type=5 exists in the feed, then block-based interlining is disabled for this feed". However, unless I'm wrong block-based interlining was never in the spec and always a Google extension that others adopted. So, it's hard to disable something that's not in the spec as that would implicitly enable it for all other feeds.

[brodyFlannigan]

Transcollines is now producing transfer_type = 5 (as well as transfer_type = 4 in our GTFS. The data can be accessed here.

[bdferris-v2]

Apologies, I got sidetracked with other work and let this one slip.

In case there was any question, the original vote did not pass. But in the meantime, we've also got a feed with transfer_type=5 from @brodyFlannigan so that's promising. Before I take next actions on this PR, I want to ask a few questions about that feed, which I'll do in a follow-up comment.

[bdferris-v2]

@brodyFlannigan thanks for the feed! Can I ask you a few follow-up questions?

Can you speak to how you decided when to specify transfer_type=5 in your feed? I see ... one transfer_type=5 entry in your feed (for trips 2022-Semaine-1.921G_T03 => 2022-Semaine-1.923C_T02). I see more entries with transfer_type=4, which is cool. I also can't help but notice that you also include block_ids in your feed (no judgement!).

So for example, for block_id=102G.2022-Semaine-1 (again, suggesting that all these trips are served sequentially by the same vehicle), we have the following trips in sequence:

• 2022-Semaine-1.941G_T01
• 2022-Semaine-1.941C_T01 (supports in-seat transfer to next trip)
• 2022-Semaine-1.943G_T01 (supports in-seat transfer to next trip)
• 2022-Semaine-1.941C_T02
• 2022-Semaine-1.941G_T02

I see you've specified transfer_type=4 for two trip pairs in this block (as noted above), indicating an in-seat transfer is possible for these trip pairs. But you didn't specify transfer_type=5 for any of the other trip pairs. Just to confirm your intention, that means that you did not want to imply that these other trips are served by the same vehicle and indeed, that should override the underlying block_id information.

By the same token, let's consider the block where you did specify transfer_type=5. Specifically, block_id=2022-Semaine-1.924C_T01 has three trips in sequence:

• 2022-Semaine-1.924C_T01 (supports in-seat transfer to next trip)
• 2022-Semaine-1.921G_T03 (does not support in-seat transfer but trips are linked by same vehicle)
• 2022-Semaine-1.923C_T02

Here, either transfer_type=4 or transfer_type=5 has been specified for all trip pairs in the block. That seems reasonable.

So, coming back to my main question: can you speak more to how you decided when to specify transfer_type=5 (and when you did not)?

[brodyFlannigan]

Hi Brian,

• In all of these cases, transfer_type = 4 is used to explicitly allow in-seat transfers between the trips, usually when a vehicle changes routes at the terminal (I.e. arrive at terminal as 941 inbound, become 943 outbound), which is interesting to passengers who are along the 941 in this case, as they get direct access to areas served by the 943.
• Additionally, the tool we use for the timetables on our website (GTFS-to-HTML) will probably start making use of transfer_type = 4 to display continuations when the field is available.
• The same logic applies to transfer_type = 5. It is used to explicitly forbid an in-seat transfer in this particular case for various policy reasons, and we've seen the continuation displayed before in some apps (because of the block_id field and the relative closeness of the end/start points of these trips), so we want to explicitly prevent it from being displayed.
• The cases where nothing is specified in transfers.txt but a block_id link exists are "driver discretion" cases where we cannot guarantee a continuation will take place and we don't actively advertise it, often because of a deadhead where the bus displays "En transit" (Not in service).
• The reason we still use the block_id field is because our real-time producer makes use of it for the assignment of vehicles to blocks. Therefore, removing it would become problematic. It also allows consumers to propagate delays across subsequent trips (which is good since the Transcollines network is very vast and delays can grow quickly especially during adverse weather conditions).

I hope this answers your questions.

Brody Flannigan
Open data & on board passenger information systems consultant
Régie intermunicipale de transport des Collines (Transcollines)

[bdferris-v2]

@brodyFlannigan thanks! A few follow ups:

The same logic applies to transfer_type = 5. It is used to explicitly forbid an in-seat transfer in this particular case for various policy reasons, and we've seen the continuation displayed before in some apps (because of the block_id field and the relative closeness of the end/start points of these trips), so we want to explicitly prevent it from being displayed.

If the spec was more explicit about in-seat transfer behavior (namely, the addition of the line"If the trips associated with an agency include any linked trip in-seat transfers, as specified via transfer_type=4, then no implicit in-seat transfers should be created using block_id-based heuristics for any trips associated with that agency.") would you still have specified transfer_type=5?

The reason we still use the block_id field is because our real-time producer makes use of it for the assignment of vehicles to blocks. Therefore, removing it would become problematic. It also allows consumers to propagate delays across subsequent trips (which is good since the Transcollines network is very vast and delays can grow quickly especially during adverse weather conditions).

If your real-time producer supported transfer_type=5 semantics fully, would you drop the block_id field and switch to providing transfer_type=5 semantics for all connected trips?

[brodyFlannigan]

Hi Brian,

Sorry about the delayed response. Here are the answers to your questions

If the spec was more explicit about in-seat transfer behavior (namely, the addition of the line"If the trips associated with an agency include any linked trip in-seat transfers, as specified via transfer_type=4, then no implicit in-seat transfers should be created using block_id-based heuristics for any trips associated with that agency.") would you still have specified transfer_type=5?

Yes, as the in-seat transfer is explicitly forbidden in "real-life", therefore I feel it is relevant to include it in the data to express the explicit nature of this operational practice.

If your real-time producer supported transfer_type=5 semantics fully, would you drop the block_id field and switch to providing transfer_type=5 semantics for all connected trips?

Possibly, however this is not currently envisioned by our RT producer. Should the full semantics become supported by our producer, we would re-evaluate the relevance of the block_id field at that time.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[isabelle-dr]

Ping @bdferris-v2, do you want to revise this PR?

[tesobota]

Our agency is implementing a route network change in June of this year, and our planned GTFS feed is testing implementation of (passenger-facing) transfer_type 4 AND 5 values - while also maintaining our consistent output of block_id "vehicle" data.

Our intent is supplementing these additional transfers of from stop/trip to stop/trip items with a value of 4 - where passengers can anticipate being able to stay in vehicle between trips (same block_id), and from stop/trip to stop/trip items with a value of 5 - where passengers can anticipate being asked to exit the vehicle at the final stop of the arrival trip and needing to re-enter at the (same/nearby) departure stop for the departure trip (same block_id).

Our agency did try using the open source tool referenced above, to "automatically" read in our GTFS feed data (block_ids) - in order to generate the "universe" of from stop/trip to stop/trip items.

Our agency does make internal use of the block_id values (for vehicle operation/tracking purposes), so we would hope to avoid needing to follow on the apparent path of Boston MBTA (that seems to purge block_id values from the version of the GTFS they submit to Google, while keeping block_id values in their "standard" feed)

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[isabelle-dr]

@bdferris-v2 are you planning to continue this PR, maybe with the editorial changes and cleanup?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process.