Wikipedia talk:WikiProject Classical music

LilyPond

Is there an official preference for LilyPond over images of scores in music articles?Trumpetrep (talk) 22:12, 21 February 2026 (UTC)

Not that I know, and I don't think there's a general preference. However, many user-supplied score snippet images are faulty and it's difficult to correct them. LilyPond allows for relatively easy corrections/improvements and, where meaningful, allows sound output. Horses for courses. -- Michael Bednarek (talk) 01:34, 22 February 2026 (UTC)

There certainly should be a preference for any scalable representation over a pixel image. Lilypond is a popular system, but it is a niche format; musicXML is editable by any number of music score programs, and would seem optimal. Imaginatorium (talk) 03:46, 22 February 2026 (UTC)

LilyPond is supported by the Mediawiki Score extension and thus available on enwiki; musicXML is not currently. Cheers, SunloungerFrog (talk) 08:08, 22 February 2026 (UTC)

If you would like to support the eventual deployment of my 3 year-old patch to the Score extension that makes it generate beautiful SVG graphics instead of the poor resolution PNG images it currently generates, please comment or vote on the 13 year-old Phabricator ticket T49578. Squeaky wheels get the oil. Currently held up by server upgrades, T385404 — Jonathanischoice (talk) 02:41, 23 April 2026 (UTC)

COI edit request relevant to this project: Derek Han

Just notifying members of this project that there is a Conflict of Interest edit request relevant to this WikiProject at the Derek Han article. DrThneed (talk) 06:31, 7 March 2026 (UTC)

Symphony of Dialogue

Not sure if this is worth rescuing, but it has been WP:PRODed. Best.4meter4 (talk) 4meter4 (talk) 15:10, 7 March 2026 (UTC)

Thanks for mentioning it here, User:4meter4. If an editor does bother to rescue it, they should also take a moment to add some citations to an article that is completely devoid of sources. Trumpetrep (talk) 23:14, 7 March 2026 (UTC)

There's a rather large section in a PhD thesis here, but other than that I'm drawing a blank. UpTheOctave! • 8^va? 19:36, 9 March 2026 (UTC)

Regular temperament

Regular temperament has been nominated for deletion. Trumpetrep (talk) 17:19, 7 March 2026 (UTC)

COI edit request relevant to this project: Folias Flute and Guitar Duo

Just notifying members of this project that there is a Conflict of Interest edit request relevant to this WikiProject at the Folias Flute and Guitar Duo article. DrThneed (talk) 01:42, 11 March 2026 (UTC)

RfC: amending project guidelines on infoboxes

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

TLDR: Proposed change adopted. Further discussion is advised to guide future editing of infoboxes related to this topic.

Long version:

There is a lot to untangle here, and a number of policies, guidelines, and decisions to apply.

• This discussion was properly advertised as an RFC (when the tag is applied, people beyond watchers of this page are notified, and related WikiProjects were also notified). That means it represents community-wide consensus equivalent to the MOS, not merely the opinions of people involved with a specific WikiProject. WikiProject guidelines are commonly used to document community-wide consensus on specific topics, though they can also document merely WikiProject-wide consensus (and the difference often doesn't matter because the most interested editors tend to communicate through WikiProject pages). Though this project page is tagged as a non-binding advice page, rules that are supported by RFC outcomes are binding no matter where they are documented.

• Though the MOS says infobox disputes should be decided on a case-by-case basis, it's common to have a topic-wide consensus where the MOS is silent or allows variation. It is OK for an RFC like this one to declare a specific guideline for a group of similar articles, saving a lot of time compared to having the same discussion on every article talk page, and improving consistency for readers. It's difficult to make a guideline that can be used site-wide all at once, and making decisions topic by topic is a good way to build up a coherent guideline over time, or at least to map out which topics go one way and which go another due to topic-specific considerations. When there are topic-specific rules, I try to link to those from the relevant MOS page, which in this case would be Wikipedia:Manual of Style/Infoboxes. That helps iron out any conflicts and also helps awareness that a topic-specific rule exists.

• Assertions that only certain editors are qualified to have opinions on this question (which I would call "tribal") appear to me to violate WP:OWN, and comments made by AirshipJungleman29 went so far that I would regard them as a personal attack on another editor. I am inclined to disregard participants who do not respect fellow editors from diverse backgrounds and work with them all collaboratively.

• The claim made on the WikiProject page is that there is a current consensus among project participants to disallow infoboxes without consensus on individual article talk pages. That claim was challenged on the grounds that it is outdated. Participants in this RFC seem to be split on the question of whether infoboxes should be advised against topic-wide. If editors giving tribal justifications are excluded, there's a consensus that they should not be prohibited by default. It seems the current claim is false, and the proposed text removes it, so it seems logical to adopted the proposed text.

The "What now?" section asks a question which I think is answered by Wikipedia:Arbitration/Requests/Case/Infoboxes this way: "The Arbitration Committee recommends that a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article."

Though it seems there is no consensus to ban or mandate infoboxes on all classic music biographies, if editors can list articles for which a local consensus has been established one way or the other, it might be possible to spot patterns. Wikipedia:WikiProject Composers § Biographical infoboxes has a good list of specific problems found in biographical infoboxes. If it's easy to write an infobox that avoids these problems (perhaps because a given composer is easy to explain), maybe it's OK to do so. If it's difficult to avoid these problems, maybe don't have an infobox for that biography.

Alternatively, it might be possible to write guidelines that short-circuit common problems. For example, it sounds like there are troubles around selecting prominent works. Can a guideline be written for how to select infobox-featured works properly? For example, the top 3-5 most recognizable to modern audiences or influential to the genre, followed by a section link to a complete list? Or should that field be omitted or always only link to a section listing all works? I have no particular opinion on the correct answers, I'm just trying to inspire creative and actionable compromise.

If there isn't consensus on how a given field should be treated, that's OK, but it would be helpful to document the areas of disagreement. For example, which fields are non-controversial (birth and death dates and locations?), which fields are generally advised against (e.g. religion is proscribed by MOS:INFOBOXRELIGION), and which fields have an unresolved controversy (genre?).

-- Beland (talk) 05:01, 3 May 2026 (UTC)

---

Should the guideline on infoboxes at Wikipedia:WikiProject Classical music/Guidelines be changed from:
Infoboxes are neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article. However, current consensus among project participants holds that biographical infoboxes are often counterproductive on biographies of classical musicians, including conductors and instrumentalists, because they often oversimplify issues and cause needless debates over content; and that they should not be used without first obtaining consensus on the article's talk page. This position is in line with that reached by the participants at the Composers Project. Links to the various infobox-related discussions from 2007 to 2013 are provided at Wikipedia:WikiProject Classical music/Major discussions.
to:
Infoboxes are neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article. If there is a dispute over whether to include an infobox, which infobox to include, or which parts of the infobox to use, it should be resolved through discussion and consensus among the editors at each individual article. (strikethroughs are original text at start of RfC; bold is amended text as of March 27) Dronebogus (talk) 17:04, 23 March 2026 (UTC) (amended March 27 2026)

Support as proposer. Dronebogus (talk) 17:05, 23 March 2026 (UTC)

Support. This would be consistent with the change WP:OPERA made in 2019. --Gerda Arendt (talk) 17:25, 23 March 2026 (UTC)

Reluctant Support (invited by the bot) I like the text that is proposed for removal...."oversimplify issues and cause needless debates over content" and "when in doubt, leave it out" is a good rule for info box content. But putting this prescriptive wording, and under composers specifically is wp:creep and so I support the removal.North8000 (talk) 18:46, 23 March 2026 (UTC)

That seems more like an opinion best kept in a personal essay anyway. Best-practice guidelines should just stay neutral on contentious matters like these. Dronebogus (talk) 18:57, 23 March 2026 (UTC)

??? I gave my opinion in an RFC and my rationale for it. North8000 (talk) 19:48, 24 March 2026 (UTC)

Comment: @Dronebogus, due to the nature of infobox discussions, which members of WikiProject Composers and WikiProject Opera were heavily involved in previously, why has this RfC not been publicised more widely? I am an advocate for using infoboxes in most cases, but I don't see why the aforementioned projects (as well as WikiProject Music) were not notified given the history here, which surely deserves a greater outreach to find wider consensus. Thanks, UpTheOctave! • 8^va? 14:26, 24 March 2026 (UTC)

Feel free to notify them if you think it’s appropriate Dronebogus (talk) 14:28, 24 March 2026 (UTC)

I will do so now, but please consider doing it yourself in the future. UpTheOctave! • 8^va? 14:29, 24 March 2026 (UTC)

Support If it's consensus by article, it's consensus by article. PianoDan (talk) 14:30, 24 March 2026 (UTC)

• Bad RfC The point of an RfC is to "invite comment from a broader selection of editors" to avoid a WP:LOCALCONSENSUS on articles or WP:PAGs. A WikiProject is by definition a narrow selection of editors who can only produce a local consensus; a WikiProject guideline is pretty much the definition of a local consensus. @Dronebogus, North8000, and PianoDan: can anyone explain what is the benefit of us non-participants adjusting the internal advice of this WikiProject? If the point is asserting that internal project pages are always subservient to wider PAGs, why is this an RfC and not a nomination for deletion? ~~ AirshipJungleman29 (talk) 15:16, 24 March 2026 (UTC)

  I actually do not understand what you are complaining about here. If you don’t want to participate who cares? It’s mainly going to be people who are already interested in this topic participating. That’s kind of obvious. Wikipeojects are not closed organizations that can gatekeep who gets to participate in related discussions and how. Dronebogus (talk) 15:28, 24 March 2026 (UTC)

  Are you interested in this topic? What contributions have you made to classical music articles? ~~ AirshipJungleman29 (talk) 15:35, 24 March 2026 (UTC)

  I’m interested (for lack of a better word) in the topic of infoboxes. More importantly my point about gatekeeping still stands. It’s even weirder being gatekept by someone from outside the project. I spent quite a while discussing this with other users on Wikipedia talk:WikiProject Classical music/Guidelines and the general consensus there seemed removal was a good idea; I started the RfC since nobody objected after a reasonable amount of time and there obviously wasn’t enough input at the guideline talk to implement on that consensus alone. Dronebogus (talk) 15:52, 24 March 2026 (UTC)

  So no, you are not interested in this topic, and are wasting the community's time with an RfC about a page which has "has no actual authority", as you say. Why? Point-scoring, it looks like. Heigh-ho. ~~ AirshipJungleman29 (talk) 18:51, 24 March 2026 (UTC)

  It's commendable that User:Dronebogus is trying to solve a perennial problem. Trumpetrep (talk) 17:49, 27 March 2026 (UTC)

  AirshipJungleman, by that logic any RFC on any Article Talk page - where most RFCs do take place - can only produce a consensus that is even NARROWER and MORE "local" than one that is held on a Wikiproject page. But the act of having an RFC kind of by definition makes the consensus not local. The project luggage might have limited scope, but if an RFC is held regarding what is written on the project page, that particular consensus isn't "local". ~2026-19011-03 (talk) 02:00, 27 March 2026 (UTC)

  WP:LOCALCONSENSUS explicitly states that a group of editors (whether or not a WikiProject) decid[ing] that relevant sitewide policies and guidelines should not apply to particular articles is impermissible, which is what I think AJ29 is referring to. Holding individual RfC's is an example of a small number of editors arriv[ing] at an agreement about how to best apply sitewide policies and guidelines to a given Wikipedia article, which is actually the desired outcome per that guideline. So no, not narrower, as it's judgement made on a case-by case-basis rather than a blanket decision. UpTheOctave! • 8^va? 10:45, 27 March 2026 (UTC)

  "if an RFC is held regarding what is written on the project page, that particular consensus isn't "local"" yes indeed, so that defeats the purpose of a WikiProject. ~~ AirshipJungleman29 (talk) 10:33, 30 March 2026 (UTC)

• Oppose No need to change. Infobox discussions attract many drive-by editors, & it does no harm to advertise that many editors actually working in the area have a particular view. Johnbod (talk) 16:00, 24 March 2026 (UTC)

  How "many", I wonder. Some had a particular view in 2010. I wasn't among them, I was so fresh to Wikipedia that I missed the RfC. How many have "a particular view" in 2026, that is the question. We should at least stop to describe the view as "current". --Gerda Arendt (talk) 20:27, 22 April 2026 (UTC)

  Just for fun I looked at the guideline (probably for the first time), they link to a list of diffs of discussions, and it all ends in 2013. One of the discussions is this, fyi. How relevant are the particular views in 2026. --Gerda Arendt (talk) 20:35, 22 April 2026 (UTC)

  ... and in the end, a link to the official RfC. --Gerda Arendt (talk) 20:42, 22 April 2026 (UTC)

  Inviting AirshipJungleman29 to inspect the basis for the so-called "longstanding consensus". --Gerda Arendt (talk) 22:12, 22 April 2026 (UTC)

  Seems a very strong basis Gerda Arendt: a lengthy discussion with large numbers of WikiProject Composers participants establishing a local consensus that was further discussed and endorsed for a number of years after. Anything wrong with it? ~~ AirshipJungleman29 (talk) 22:22, 22 April 2026 (UTC)

  Define wrong. It's dated. The same Voceditenore who proposed to close in favour of no recommendation for an infobox removed that clause from the guidelines of project opera in 2019, and was the strongest voice for an infobox in the latest Mozart RfC. It's past midnight here, otherwise I could give you a few more who changed their mind, - perhaps check yourself. The Mozart RfC, a long civil discussion with a large number of participants, seems to reflects the current (not only local) consensus much better than the 2010 one. --Gerda Arendt (talk) 22:53, 22 April 2026 (UTC)

  Then hold a new discussion with WikiProject Composers participants, not whatever this farce is. ~~ AirshipJungleman29 (talk) 10:31, 23 April 2026 (UTC)

  It has been said in 2010 already that local project guidelines are not binding. They were adopted to this project Classical music (not only Composers). We editors in the field (project members and others) can do what we have done for years: ignore them. If we want guidelines to follow reality, we have to discuss here. The question is: do we want to retain a local difference for these projects from the MoS? I said no, and it has worked for project opera for several years now. --Gerda Arendt (talk) 11:01, 23 April 2026 (UTC)

  I don't know, I don't care, and I shouldn't care because I'm not part of this project. ~~ AirshipJungleman29 (talk) 11:13, 23 April 2026 (UTC)

• Oppose on principle people not involved in the topic area covered by a Wikiproject should not be importing disputes from a contentious topic into the non-binding advice given by the Wikiproject, via RfC or otherwise. --JBL (talk) 18:00, 26 March 2026 (UTC)

  You seem not to know that first came the present wording, in 2010, and that caused the topic to become contentious. Our goal might be to get back to the former wording, and free the topic from being regarded as contentious. Of the users who supported the 2010 RfC, some died, some left, some changed their mind. I wonder for how long we will retain the clause that sets this project apart from the rest of Wikipedia. --Gerda Arendt (talk) 20:21, 22 April 2026 (UTC)

• Oppose. "Infoboxes are neither required nor prohibited for any article" is contradicted by "Whether to include an infobox...is determined through discussion and consensus".

Those two statements are incompatible.

The second statement is the very prohibition the first statement claims does not exist.

As we have recently discussed, these guidelines are misleading. They should reflect reality, and this language does not.

What we should discuss is getting rid of the jury-rigged ban on infoboxes altogether. Trumpetrep (talk) 17:37, 27 March 2026 (UTC)

Should the statement be amended to say “if there is a dispute over whether to include an infobox, which infobox to include, or which parts of the infobox to use, it should be resolved through discussion and consensus among the editors at each individual article”? Because now that you point it out it can definitely be misread as what you are saying, but my understanding was that it should be read as what I just suggested. Dronebogus (talk) 19:48, 27 March 2026 (UTC)

I am not seeing the conflict here at all. Saying "each individual article will have its own consensus on whether to include an infobox," strikes me as essentially identical to "there is no global ban or requirement for infoboxes." PianoDan (talk) 20:00, 27 March 2026 (UTC)

"If there is a dispute" ignores the reality that a pre-existing dispute exists which bans infoboxes in certain articles. There is a prior restraint on adding them which the guidelines should reflect.

Essentially identical ≠ Identical.

The guidelines mischaracterize reality. They should reflect it. Trumpetrep (talk) 20:08, 27 March 2026 (UTC)

If nobody else cares, I can just amend it to the suggested text; pinging @North8000: @Gerda Arendt: if you would care/change your vote if I changed the text to the bolded variant Dronebogus (talk) 20:41, 27 March 2026 (UTC)

I agree to that text. After the guideline change, we should remove the hidden messages in some articles that were based on the restrictive former guidelines. Like here. --Gerda Arendt (talk) 21:09, 27 March 2026 (UTC)

Oppose and thanks for that link - the note at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Composers#Biographical_infoboxes perfectly sums up the huge problems with boxes in the field of classical music. Cg2p0B0u8m (talk) 22:34, 27 March 2026 (UTC)

It's also an unscientific assertion. "Many members of this project think that Infoboxes are seldom useful ..."

How many? Is it a majority? Why does this idiosyncrasy matter? Why should "many members", which may not be a majority, be able to ban something?

Earlier this month, I amended the guidelines at Wikipedia:WikiProject Classical music/Guidelines to properly reflect reality: "Infoboxes are neither required nor prohibited for any article, except for biographies of classical musicians where they are prohibited without prior consensus."

User:Dronebogus undid those revisions because he felt like this larger discussion needed to take place. There are always multiple paths forward on Wikipedia. Whichever path is chosen, the bottom line remains the same: there is a ban on infoboxes at certain articles which blindsides well-meaning editors.

We should either A) stop surprising editors by updating the guidelines to reflect the ban or B) get rid of the ban. Trumpetrep (talk) 22:48, 27 March 2026 (UTC)

There is no ban. You can add infoboxes to articles that you write without protests. The last time I had to defend one (for Max Reger) was in 2016. --Gerda Arendt (talk) 23:03, 27 March 2026 (UTC)

That's a pretty major qualifier:

No ban to articles that you write.

There absolutely is a ban on adding infoboxes to articles that you did not write. The guidelines should reflect reality.

When an editor like User:Antniomanso adds an infobox to Rimsky-Korsakov's article in good faith, he is absolutely blindsided by the ban. Editors waste time debating it all over again when we could either A) make the guidelines a clear reflection of reality or B) get rid of the ban. Trumpetrep (talk) 23:16, 27 March 2026 (UTC)

• Support the proposed text is less wordy, more clear, and better reflects MOS:INFOBOXUSE Shogeneral (talk) 01:03, 7 April 2026 (UTC)
• Oppose on principle because a {{WikiProject advice}} page should be treated like a user essay, and that means that other editors shouldn't mess with it (but are free to write their own essays to disagree with it). I'd suggest renaming this (e.g., /Guide instead of /Guideline). Also, the OP is currently involved in an ArbCom case that touches on this subject, so the timing of this RFC is unfortunate. WhatamIdoing (talk) 18:59, 20 April 2026 (UTC)

  The problem is that this advice led to hidden messages in articles which try to prohibit normal editing, but request that permission for an edit has to be obtained on the talk page (one variant, see Debussy: "Before adding an infobox, please consult Wikipedia:WikiProject Composers#Biographical infoboxes and seek consensus on this article's talk page.") or prohibit an edit without even offering that possibility (see Verdi until recently: "Do not add an infobox on this page. See: https://en.wikipedia.org/wiki/Talk:Giuseppe_Verdi/Archive_1#Infobox"). They have come to be mostly ignored, but what will a new editor of the encyclopedia that anyone can edit understand? --Gerda Arendt (talk) 21:03, 20 April 2026 (UTC)

  I assume that such messages were placed before Wikipedia talk:WikiProject Composers/Infoboxes RfC and should be removed (but not by you personally). WhatamIdoing (talk) 02:14, 29 April 2026 (UTC)

  Also: the present wording uses the term "current consensus", "current" being a no-no-word anyway, and in this case meaning 2010. That at least should be changed. --Gerda Arendt (talk) 21:09, 20 April 2026 (UTC)

  It would be more pointful for the message to clarify that even if it's an up-to-the-minute consensus by the group, it's just the group's consensus, and not the whole community's. WhatamIdoing (talk) 02:14, 29 April 2026 (UTC)

  If it's supposed to be treated as a user essay, who can edit it then? Katzrockso (talk) 11:36, 28 April 2026 (UTC)

  Anyone who believes themselves to be a participant in WikiProject Classical music, keeping in mind that Wikipedia:A WikiProject is a group of people and not a subject area. WhatamIdoing (talk) 02:10, 29 April 2026 (UTC)

  Then on what basis can you oppose any changes to it. Nothing stops everyone here from saying they consider themselves participants in WikiProject Classical music. Katzrockso (talk) 03:42, 29 April 2026 (UTC)

  Except that they don't say that, do they? WhatamIdoing (talk) 18:28, 29 April 2026 (UTC)

  Well without asking each and every editor to declare whether they are a member of the WikiProject, how do we know? I'd say anyone who is interested enough to !vote in the RfC could conceivably be considered a member Katzrockso (talk) 02:00, 30 April 2026 (UTC)

• Support. In spite of the fact that the existing WikiProject text is supposed to be entirely non-binding, it acts to protect very definite hidden warnings within articles. Rudolf Schwarz (conductor) includes the hidden text "<!-- please do not add an infobox, per [[Wikipedia:WikiProject Classical music#Biographical_infoboxes]]-->". Many editors seeing that will not realise it's contrary to the Wikipedia-wide consensus, and even those that do may well steer clear as it's obvious that at least one editor feels really stongly and may well turn up and start an argument. MichaelMaggs (talk) 09:07, 21 April 2026 (UTC)
  • It might be reworded, but I see no harm in this, or the ones Gerda quotes; it prevents or at least drive-bys adding a box without discussion, which otherwise they are very likely to do. Yes, adding one may start an argument, so a warning seems appropriate. Johnbod (talk) 04:17, 25 April 2026 (UTC)

    Such wording is a clear infringement of WP:LOCALCONSENSUS, in that it improperly attempts to enforce the need for prior permission to make a certain type of edit that some WikiProject members disapproved of when last asked, 16 years ago. Improper WikiProject attempts at enforcement don't become acceptable by recharacterising them as harmless warnings that the editor might start an argument. In any event, the purpose of this RFC is to overturn that old one, regardless of its validity or otherwise. MichaelMaggs (talk) 18:02, 27 April 2026 (UTC)

• Support as a clear improvement to the status quo that better reflects how the rest of Wikipedia works. Neither WikiProject Classical music nor classical music articles are somehow special in any way that means infoboxes are somehow better or worse in this topic area than any other. They are appropriate for at least most articles on concrete subjects. Thryduulf (talk) 21:51, 27 April 2026 (UTC)
• What's the point? The amount of time sunk into this RfC is already saddening, especially given the concurrent ArbCom case. However, we are here now, so I hope the following comments will at least help end the former for good.

To start, this is a WikiProject advice page. Per WP:LOCALCONSENSUS, it is overruled by MOS:INFOBOXUSE:

The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

Both the current and proposed versions incorrectly parse this:

• Ignoring the statement of local opinion, which may or may not be outdated, the current version's claim that infoboxes should not be used without first obtaining consensus on the article's talk page ignores WP:IMPLICITCONSENSUS (an edit has presumed consensus until it is disputed or reverted). Therefore, it is true that this promotes an impermissible local consensus, which has been used as a way to dissuade the addition of infoboxes through the use of flawed hidden comments.
• On the flipside, the proposed version is an incorrect gloss of the MOS guideline: discussion and consensus always determine these decisions regardless of whether there is a dispute or not. Consensus is Wikipedia's fundamental method of decision-making (WP:CON), and this case is no exception: ironically, in trying to remove a local consensus, this wording would create one itself, as it suggests that until a dispute occurs the pursuit of discussion and consensus is not required.
• Furthermore, the now-struck original proposal is just the MOS guideline verbatim, so it is actually the only version that does not create a local consensus, but is entirely redundant.

Therefore, there is no information in any of the three options (the current version or either proposal) that is advice about how to apply Wikipedia's policies and guidelines to their specific subject area (WP:ADVICEPAGE): rather, they contain redundancy in the best of cases, and impermissible local consensuses in the worst. I see two solutions:

1. We get rid of that section altogether, as it is either useless or actively harmful.
2. Alternatively, if we want to have something, it should be unpartisan. Otherwise, we will likely again fall into the trap of providing a confusing, contradictory statement, which is not advice. WikiProject Opera's current infobox advice seems to be a good model that I suggest we use, as it quotes the MOS and contains useful advice on how to add the appropriate infoboxes if required.

Regardless, we should remove or reword all the hidden comments, as they promote an impermissible and unenforceable local consensus.

Personally, I'm ambivalent on infoboxes; not that it matters, I think they're great for some topics, but fall short for others. I've never really understood the division this topic prompts: it does not matter if you love infoboxes, or vehemently hate them: we should follow the MOS regardless. If we really want to leave the days of disputes prompted by flawed local consensuses behind us, let's just let it go, move on, and go by the MOS: as I show above, we are losing nothing. UpTheOctave! • 8^va? 23:25, 27 April 2026 (UTC)

I agree that we should let go and move on, considering that there are 7 (8 if counting your message) supports and only 2 opposes with regards to changing the guideline itself. I think the WP:Opera model would be more useful than removing the section entirely and would also be a good compromise, as it would allow past discussions to be linked so the reader can see the dispute around infoboxes. Shogeneral (talk) 23:49, 27 April 2026 (UTC)

• Oppose I concur with the reasonings of the other opposing editors that such a change is unneeded and likely to cause more confusion, not less. Barbarbarty (talk) 15:57, 1 May 2026 (UTC)

  The current guideline conflicts with the MOS, as per User:UpTheOctave!'s comment. How could a section modeled on WP:Opera cause more confusion? Shogeneral (talk) 18:15, 1 May 2026 (UTC)

What now?

For those who lack fluency in Wikipedia's bureaucratese, what are the next steps to this never-ending debate? Trumpetrep (talk) 19:43, 29 April 2026 (UTC)

Someone uninvolved with the subject comes along and closes it: see WP:RFCCLOSE. The discussion has actually overran the usual 30 days timeframe for RFCs, so making a neutrally-worded closure request would also be valid when activity has sufficiently died down (the best way to tell is when there is little or no activity in the discussion, or further activity is unlikely to change its result). UpTheOctave! • 8^va? 19:49, 29 April 2026 (UTC)

My question was more holistic than that.

What do we do now about this never-ending debate, once this latest round is closed? Its recurrence demonstrates the need for a clearer policy. Trumpetrep (talk) 21:07, 29 April 2026 (UTC)

Ah, I see what you mean. At its root, this is fundamentally a philosophical disagreement about editorial values, so it is likely to resist attempts to legislate it out of existence. In my opinion, the MOS guideline is decently clear as long as it is followed, and is likely the best mechanism we could devise: we should go on a case-by-case basis, discussing individual aspects that would be reasons for/against an infobox for that page to find a consensus (incidentally, there is currently an RfC on what these factors could be, which readers of this page might be interested in). Recurrence is natural when you consider the lengthy history of this dispute (which has thankfully been a lot less heated in recent memory); I think some level of healthy discussion is never a bad thing – I mean, it's how we sometimes achieve progress, and I'm yet to find a better way. UpTheOctave! • 8^va? 23:32, 29 April 2026 (UTC)

The case-by-case policy is precisely what leads to these recurring dustups. Trumpetrep (talk) 00:08, 30 April 2026 (UTC)

What else would you suggest then? UpTheOctave! • 8^va? 00:14, 30 April 2026 (UTC)

All that's required is the first sentence of the policy: they're neither required nor prohibited.

As for the red tape, I have no idea how to proceed, which is why I asked what to do next. Trumpetrep (talk) 00:17, 30 April 2026 (UTC)

I don't really follow. Removing the second sentence wouldn't remove the case-by-case framework: if infoboxes are neither required nor prohibited, then it is a natural conclusion that their inclusion is determined by something that isn't universal; ergo they are still decided on a case-by-case basis by any other name. A shorter guideline isn't necessarily clearer, it just removes the mechanism to determine whether to use an infobox or not, which arguably leaves us more stranded than before.

Regardless, if you want to propose this, the relevant place would be at Wikipedia talk:Manual of Style/Infoboxes, using the procedure outlined at WP:RFCOPEN. UpTheOctave! • 8^va? 00:28, 30 April 2026 (UTC)

The first sentence is the policy. It's like so many of our policies here. It's open-ended, and it allows a collaborative approach.

That's all that needs to be said. The second sentence is where the can of worms gets opened.

Thanks for explaining a process. I'd be willing to bet that if I followed your advice, another editor would immediately reprimand, "The proper venue for this is..." Trumpetrep (talk) 00:42, 30 April 2026 (UTC)

Someone (or a group of someones) still has to decide on a case-by-case basis regardless: this just makes it unclear how to go about deciding, as it doesn't describe a mechanism to do so. A case-by-case basis is open-ended by definition, just like how describing a method of acheiving consensus with discussion is a collaborative approach. There must be some discussion to decide, but this is not a recurrence of the central dispute as you suggest: that's just what it practically means to determine whether an infobox is used or not, and is actually evidence that the MOS guideline is working.

Also, this has been the guideline since 2011. It's not that this is a process: given the history of infoboxes, you are extremely unlikely to change the guideline without a well-publicised talk page discussion (usually an RfC). You can read more at WP:PGCHANGE and act on the advice I've given, or not, but that's wholly up to you. I'm going to stop replying now as this is getting off topic for this page. If you end up proposing anything at the MOS talk page, feel free to ping me, and I'd be happy to talk more. UpTheOctave! • 8^va? 01:28, 30 April 2026 (UTC)

What is recurring are the sprawling dustups about infoboxes in general, such as this one. They demonstrate the inutility of the policy. Trumpetrep (talk) 01:34, 30 April 2026 (UTC)

Is it safe to say that the discussion has run its course? If so, I can make a neutrally-worded closure request. Shogeneral (talk) 22:48, 30 April 2026 (UTC)

I have no objections to that. UpTheOctave! • 8^va? 22:51, 30 April 2026 (UTC)

Please do. MichaelMaggs (talk) 10:40, 2 May 2026 (UTC)

@MichaelMaggs they already did. Thryduulf (talk) 11:26, 2 May 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Close clarification

(moved from User talk:Beland to put this clarification on the official record)

Hi Beland, many thanks for your close of the recent RFC at WikiProject Classical music. I'm writing to ask for some clarification for the record, particularly on this part: if editors giving tribal justifications are excluded, there's a consensus that they should not be prohibited by default. It seems the current claim is false, and the proposed text removes it, so it seems logical to adopted the proposed text. I welcome your finding that the original text was falsified by time, but I'm worried that there may be a non sequitur in your logic, as other proposed alternatives were not mentioned despite being equally viable considerations. As I warned about in my !vote, I believe the new guideline is an improper gloss of the MOS that misrepresents the application of implicit consensus; compare the following (L: MOS, R: WikiProject):

−

The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

+

Infoboxes are neither required nor prohibited for any article. If there is a dispute over whether to include an infobox, which infobox to include, or which parts of the infobox to use, it should be resolved through discussion and consensus among the editors at each individual article.

As written, this version implies that consensus does not apply to the addition of infoboxes until a dispute occurs, which is contrary to the consensus policy. Since you note that this RFC represents community-wide consensus equivalent to the MOS, we now have a subtle conflict in our guidelines. To avoid any confusion, I have several questions that I think should be answered; I would welcome an addendum to the close addressing these points:

1. How does this closure account for the policy-based implicit consensus in an article's status quo (having or not having an infobox)?
2. Exactly which "tribal" !votes were discounted?
3. Why was this proposed text selected rather than any of the alternatives offered by commenters? As you used the word "logical" rather than identifying a consensus to adopt the new text, was the actual consensus found in your close just to remove the old text? If so, do you regard the new guideline as representing community-wide consensus equivalent to the MOS?
4. Is this wording equivalent in meaning to the MOS? If not, does this guideline supersede or yield to the MOS in this topic area, or are they to be read together? If the last, how is the difference in wording reconciled?
5. Does this change in consensus justify the removal of the hidden comments, as mentioned by many in the RFC?

Thanks for your time and effort in closing this, and apologies for the additional questions. I look forward to your responses and hope they can serve as clarification for other editors. Best, UpTheOctave! • 8^va? 14:58, 3 May 2026 (UTC)

1. Your objection that was based on implicit consensus was to the older text, which has been removed. As for the new text, my reading of WP:IMPLICITCONSENSUS is that the implicit consensus imputed by an edit going unchallenged for a while can be changed by a new edit that goes unchallenged for a while. The fact that an article has had or not had an infobox for a long time does not count as a local consensus for the purposes of this guideline; a talk page discussion reaching general agreement does. WP:IMPLICITCONSENSUS says that repeated reverts are not an appropriate way to demonstrate consensus; the talk page should be used instead.
2. The "tribal" comments I refer to were from JBL and WhatamIdoing, in addition to AirshipJungleman29's personal attack.
3. I said "logical" because whether there's an affirmative consensus depends on excluding votes for behavioral issues, but lack of consensus to continue a ban is clear. It did not seem appropriate for me to come up with my own text; the text proposed by the RFC is fit for purpose, supported by 6 participants, and has been adjusted in response to your criticisms, even if it did not win your support. I did not see support among enough participants for deleting this outright, though that would be a clear way of syncing it with the MOS and reduce bloat. If my recommendation to list factors that identify good vs. bad infoboxes is taken up, this section will continue to exist, but if you have strong feelings, that amendment might be a good vehicle to trim the redundant wording in favor of a link to the MOS.
4. Yes, the new text and the MOS text mean the same thing. Unless there is an existing per-article consensus not to have an infobox, editors can add one to any classical music biography. If there is a pre-existing per-article consensus to have an infobox, an existing one cannot be removed without a new consensus. If the addition is challenged, or the removal or modification of an existing infobox is challenged, that is resolved "through discussion and consensus among the editors at each individual article". I see why you are raising an objection; the full meaning of both requires application of common sense and context about how disputes are typically resolved. The procedure is not necessarily crystal clear like a mathematical proof or computer program. If you have strong feelings that this is not OK due to concerns about wikilawyering or novice editors, you might propose a clarifying amendment to the MOS text. This sort of rule is common across the MOS, and such an attempt may encounter pushback from editors who say everyone already knows what is meant, and opposing making the MOS more verbose. Personally, I don't have a strong opinion.
5. Hidden text must follow WP:HIDDEN. So yes, those that say an infobox should not be added because of text on e.g. Wikipedia:WikiProject Classical music or Wikipedia:WikiProject Composers should be removed, as neither of those pages currently ban infoboxes. The rules on WP:BADHIDDENTEXT mean that hidden text can advise editors to consult the article talk page for the current local consensus before adding or removing an infobox, but it prohibits comments that say an infobox can never be added or removed (because consensus can change, including in response to a proposal made by an editor coming across a hidden comment).

-- Beland (talk) 19:27, 3 May 2026 (UTC)

Thank you very much, this clears things up a lot. No. 4 in particular alleviates a lot of my other concerns, which rode on the possible interpretive discrepancy I identified. I have opened a discussion concerning how this clarification could be implemented into the guideline, which interested parties can find on the Guidelines talk page. UpTheOctave! • 8^va? 19:56, 3 May 2026 (UTC)

Requested move at Talk:String Quintet in E major, Op. 11, No. 5 (Boccherini)#Requested move 8 April 2026

There is a requested move discussion at Talk:String Quintet in E major, Op. 11, No. 5 (Boccherini)#Requested move 8 April 2026 that may be of interest to members of this WikiProject. TarnishedPath^talk 04:35, 23 April 2026 (UTC)

Request for help

Is there any way to find out more about William C. Graham who preceded A. J. Turner in teaching a band of blind musicians? Cake (talk) 17:02, 1 May 2026 (UTC)

I added the Template:More citations needed which includes pre-loaded search links to JSTOR, Google Books, and other sources. Trumpetrep (talk) 19:14, 1 May 2026 (UTC)

Kneisel Hall

Please add reliable sources. Thank you in advance. Bearian (talk) 01:32, 2 May 2026 (UTC)

Well-publicized community discussion

User:Beland did an impressive amount of reading and analysis to wrap up that Request for Comment.

As noted, the 2013 Arbitration decision recommended "a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article."

13 years later, administrators are still recommending this remedy.

How de we have this discussion? Trumpetrep (talk) 17:03, 3 May 2026 (UTC)

I recommend pulling together some research and workshopping with a small number of people, before holding an RFC that's advertised similarly to the previous one. I'll kick things off right now...

In tidying up related discussions, I found Talk:Wolfgang Amadeus Mozart/Archive 16 § Mozart Infobox RFC. If the resulting infoboxes on Wolfgang Amadeus Mozart and Ludwig van Beethoven and Johann Sebastian Bach are taken as precedent along with the concerns raised in that RFC, a WikiProject guideline might read like this:

Follow MOS:INFOBOXUSE when deciding whether or not to have an infobox. Infoboxes for classical music biographies that follow these guidelines are more likely to be acceptable:

• Include only basic biographical details that do not need context, for example: name, picture, birth/baptism and death dates and locations, occupations, notable family members, signature.
• Unless all notable works (those with Wikipedia articles) can be concisely listed, the infobox should only have a link to a section listing all works.
• Controversial, disputed, and complicated issues should be deferred to prose, for example: influences, the person's impact on others, genre, what the person is best known for.
• Trivial details should be omitted to avoid clutter, following due weight.

I don't have a strong personal opinion, just wanted to make a starting point for discussion. -- Beland (talk) 19:27, 3 May 2026 (UTC)

Good article reassessment for Sängerfest

Sängerfest has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. Z1720 (talk) 20:11, 11 May 2026 (UTC)

June 2026 GAN Backlog Drive

Good article nominations | June 2026 Backlog Drive
June 2026 Backlog Drive: Do you want to become more experienced in the GA process? On 1 June, a one-month backlog drive for good article nominations will begin. Barnstars will be awarded based on the number of articles reviewed. Mentors are available, and new reviewers (<6 reviews) get bonus points! Interested in taking part? You can sign up here.
Other ways to participate: Join the conversations on our talk page.
You're receiving this message because you have participated in a good article review this year or participated in the previous backlog drive.

MediaWiki message delivery (talk) 21:59, 25 May 2026 (UTC)