Hi Micru!

The Architecture Committee has decided to pick up this RFC, and see whether we can get it approved over the next days or weeks. We are currently experimenting with the RFC process, trying to adopt it to a Phabricator based workflow. It is no longer necessary for every RFC to be discussed on IRC, and decided ad-hoc.

Over the next days, I will try to assess the status of your proposal. You could help me by answering a few questions:

• Do you still want to go forward with this RFC?
• Do you have the capacity to work on the implementation of this RFC in the next weeks and months?
• What are the most important questions you need to have answered (from the ArchCom or others)?

From the RFC page on the wiki, it seems like there has been a lot of discussions, and a lot of ideas. I'm having trouble to discern a clear proposal. Could you write down which next steps you propose, in a condensed form? You could do that on here on Phab, or on the wiki (and then post a pointer here).

@Qgil @Micru it has been three years since this was first proposed. Is there still interest in pursuing this?

In T487#6467970, @Krinkle wrote:

@daniel I believe there is a more recent proposal from you about this, but I'm unable to find it now. Do I remember that right? If so, I suppose we can merge the tasks (if it has one) and/or point here from the off-Phab places.

The only related proposal I remember is T165149: RFC: Drop requirement to define a talk namespace for every subject namespace.

The use cases mentioned in the proposal are covered by MCR. I think we can close this.

TechCom is proposing to decline this RFC. The idea technically has merit and could be considered again the future.

The specific needs and use cases that led to this idea, however, appear to have since been addressed by the introducing of MCR (for associating data with a page), and by the approving of T165149 (for not requiring a talk page with every page).

That, together with the author no longer being around (predates Phabricator process), and no-one else seemingly needing this or invested in building it, led us to believing we should close this.

The Last Call will end on Oct 7. Any renewed interest or use cases may be brought up before then. Of course, it is also fine at any time to re-open or file a new this RFC using our current process and template.

Associated namespaces are distinct from MCR, IMO (although it is true that the examples suggested in the RfC make more sense for MCR - as a rule of thumb, if you need to edit or query the two things together, they should probably be in the same revision).

Bask Wikipedia's Txikipedia namespace seems like a decent use case for this proposal, though. All articles come with three pages: you have Joan Mari Torrealdai for the normal encyclopedia article, Eztabaida:Joan Mari Torrealdai for discussion and Txikipedia:Joan Mari Torrealdai for the children's encyclopedia article version of the article (with different content and layout). I guess you could do that with MCR, just like you could theoretically do talk pages themselves with MCR, but an associated namespace does seem like a nicer approach. (In practice, currently they just use normal namespaces and a JS hack for adding the extra tab. There is a Txikipedia eztabaida namespace, it's just empty and the tab that would link to it is removed. Presumably all page moves, deletes etc. have to be duplicated manually.)

So maybe reach out to them for gauging interest?

TechCom is proposing to decline this RFC. The idea technically has merit and could be considered again the future.

That is not what "Decline" means in Phabricator. I'd recommend you use the "Invalid" status instead. (Properly, we should use "Stalled", but Andre doesn't like that.)

In context of the RFC process, declining refers to the "Declined" columnn on TechCom-RFC (TechCom-RFC-Closed). Having re-reviewed our Phabricator conventions I believe "Declined" as task status is also (still) generally aligned with our use of that term:

• Declined: […] when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested. This status is also set when there's a consensus that implementing a particular task would be a bad idea. […]
• Invalid: […] does not describe an actual wrong behavior, or when it is a change that is outside the power of the component's developers. For example, tasks proposing changes to third-party software or third-party website settings […]

Based on this, I would say:

• … when TechCom proposes declining as the outcome through the last call process (as is the case on this task) then "Decline" would also be appropiate for the task itself. Specifically because that outcome will generally relate to current resourcing, current workarounds, or current proposals, and in no way invalidates the problem statement itself.
• … when TechCom triages an RFC as out of scope and declines it right away, then, if the task is only about the RFC, the "Invalid" status could be considered. We don't use this currently, but I'll take that into consideration for the next amendment. I will note however that there definitely seems overlap between the two statuses, and especialy at the meta-level of an RFC it is additionally hard to judge which is "best" given the number of different perspectives it could be seen from.

Setting to Declined sets an extremely high bar to tasks ever getting re-opened again, even more so when done "officially" on behalf of TechCom as a gatekeeper. Pretending otherwise is unhelpful.

In T487#6493426, @Tgr wrote:

Associated namespaces are distinct from MCR […]

Bask Wikipedia's Txikipedia namespace seems like a decent use case for this proposal, though. All articles come with three pages: you have Joan Mari Torrealdai for the normal encyclopedia article, Eztabaida:Joan Mari Torrealdai for discussion and Txikipedia:Joan Mari Torrealdai for the children's encyclopedia article version of the article (with different content and layout). […]

Agreed. I don't think we're dismissing the idea itself. There just isn't any place for it on the roadmap currently, no resourcing or significant interest. Are there significant drawbacks from the current workarounds on that wiki? Who would lead and own the effort to making this a first-class concept in the software?

An RFC could be filed at any time (or re-opened) for it. If there's some amount of commitment now or before Oct 7 we can keep this open. No problem :)

In general I think TechCom should find a better way of handling the "seems like a good idea but unlikely to get on the WMF's roadmap" outcome than declining it. It is incompatible with what the Declined status generally means in Phabricator, it makes the task pretty much impossible to find for any future searches, and it misses an opportunity to provide interesting tasks for future volunteers or inform future prioritization discussions (especially the parts of the movement strategy about making prioritization discussions more participative do actually get implemented).

Use the Stalled status and filter it out from the board, use a separate column or board for valid-but-unresourced RfCs, convert the task from an RfC to a plain proposal, or establish a norm that RfC tasks need to be separate from the main task proposing the idea, so TechCom can handle the task as it best benefits their workflows without interfering with the normal usage of Phabricator for discussing ideas.

@Tgr I don't agree about it being different from our defined meaning for Declined in Phabricator. As for search, each of the three search forms in Phabricator has an option to search open or search all. I will also note that there is no reason at this point for us to actually close the task using the Phabricator status. I intend to move it to the "Declined" column on the TechCom-RFC board where we have various other open tasks as well.

In general, if the reason for declining is not technical in nature, I agree it is helpful to keep the task open, and that is how we'll continue for now.

Keeping such RFCs on the main workboard makes sense to me as well. I'll make sure we include that in the next process amendment, or you can start as its own quick one if you prefer. E.g. using "stalled" in P1 or P2 and filtering them out by default on the board, would work for me. I suppose one could interpret "Stalled" as meaning something else, but we'll work out with various stakeholders what works best.