Hi all!
Here are the minutes from this week's ArchCom meeting. You can also find the minutes at https://www.mediawiki.org/wiki/Architecture_committee/2017-01-18.
See also the ArchCom status page at https://www.mediawiki.org/wiki/Architecture_committee/Status and the RFC board https://phabricator.wikimedia.org/tag/mediawiki-rfcs/.
Here are the minutes, for your convenience:
* 2 RFCs approved after final call: Deprecation Policy ([[Phab:T146965|T146965]]) and Content Model Storage ([[Phab:T105652|T105652]]). * Multi-Content-Revisions (MCR, [[Phab:T107595|T107595]]) discussed at DeveloperSummit. Sorted out details of the DB schema with Jaime. * Ongoing discussion regarding distribution methods for MediaWiki and suppor for 3rd party installs. ** Related discussion about whether new features can require services serparate from MediaWiki core. * Thumbnail API is mostly stalled for now [[Phab:T66214|T66214]]. * Oldimage RFC ([[Phab:T589|T589]]) to go on final call this week. ** Decided to keep media type and mime type fields for now. Thy are small, and now exposed via Cirrus Search; if we removed them from the table, they would need to love somewhere else. Also they are enums, and thus small. ** Tentative plan to fold image revision management into MCR at some point, but not until MCR is mature. Also, this schema change will make a later migration to MCR much easier. * ArchCom is considering changes to the RFC process. Discussion is ongoing. Key points: ** More focus on discussion in Phabricator ** More leight weight process for “small” RFCs ** ArchCom to focus more on review, less ond process ** IRC meeting should not be the primary tool for discussing and approving RFCs * Next week’s IRC discussion: [[Phab:T154738|T154738]] (Accessing page properties from wiki pages). Related: ** T71441: Feature request: add detection for disambiguation pages to Scribunto ** T131911: Allow retrieving/getting page image file name from wikitext using Scribunto/Lua or parser function or something ** T154346: Provide "wikitext" means of accessing arbitrary wiki page's default category sort key
Daniel Kinzler wrote:
- ArchCom is considering changes to the RFC process. Discussion is
ongoing.
Where is discussion ongoing?
Key points: ** More focus on discussion in Phabricator ** More leight weight process for “small” RFCs ** ArchCom to focus more on review, less ond process ** IRC meeting should not be the primary tool for discussing and approving RFCs
I don't know what primary tool means. There are benefits to both asynchronous and synchronous discussions. The IRC meetings in particular have the benefit of being scheduled and regularly recurring, which can be a good nudge for people to finish drafting a task or wiki page, to make a decision to accept or decline, to comment on a proposal, etc.
MZMcBride
Am 18.01.2017 um 21:45 schrieb MZMcBride:
Daniel Kinzler wrote:
- ArchCom is considering changes to the RFC process. Discussion is
ongoing.
Where is discussion ongoing?
Internally. We have to decide on a MO. I'm sharing this summary here to keep you posted, and give an opportunity for input. But in the end, the committee has to decide how it wants to operate.
I don't know what primary tool means.
In the past, the IRC dicussion was the only way to get an RFC discussed or approved.
There are benefits to both asynchronous and synchronous discussions. The IRC meetings in particular have the benefit of being scheduled and regularly recurring, which can be a good nudge for people to finish drafting a task or wiki page, to make a decision to accept or decline, to comment on a proposal, etc.
Yes, we do see advantages, too. But it's not the best tool for all discussions, and shouldn't be the only venue of discussion.
On Wed, Jan 18, 2017 at 10:44 PM, Daniel Kinzler < daniel.kinzler@wikimedia.de> wrote:
** Related discussion about whether new features can require services serparate from MediaWiki core.
That seems like it would be a decent RFC at some point.
Brad Jorsch (Anomie) wrote:
On Wed, Jan 18, 2017 at 10:44 PM, Daniel Kinzler < daniel.kinzler@wikimedia.de> wrote:
** Related discussion about whether new features can require services serparate from MediaWiki core.
That seems like it would be a decent RFC at some point.
Agreed.
There are often questions of debug and maintenance support and service level for production services, from the Wikimedia (Foundation) operations team and others. Clarifying the current situation and how it can be modified in the future would be useful and alleviate some of the tensions we've had, in my opinion.
The trickiness here is that some of this falls outside of the Architecture committee's purview, particularly as no member of the operations team is on the committee currently (Mark, Faidon, Alexandros, Giuseppe, et al.). In my mind, there's what MediaWiki core and its extensions can do and can require, but the relationship between MediaWiki and Wikimedia cannot be completely sidestepped. With MediaWiki as the platform, there are also questions about what wikimedia.org, mediawiki.org, wikipedia.org, and the various other Wikimedia projects are willing to host and support. RESTBase seems like a decent example of this interplay.
Daniel Kinzler wrote:
We have to decide on a MO. I'm sharing this summary here to keep you posted, and give an opportunity for input. But in the end, the committee has to decide how it wants to operate.
"You know what they call a leader with no followers? Just a guy taking a walk."
In the past, the IRC dicussion was the only way to get an RFC discussed or approved.
It depends how strictly you view requests for comments. A decent-size Gerrit changeset that gets accepted and merged in is, in some ways, an RFC, usually with one or more associated Phabricator Maniphest tasks. Sometimes with associated mailing list or on-wiki discussion.
MZMcBride
wikitech-l@lists.wikimedia.org