Jump to content

Wikipedia talk:Content assessment: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
m Archiving 1 discussion(s) to Wikipedia talk:Content assessment/Archive 8) (bot
Line 71: Line 71:


:@[[User:Audiodude|Audiodude]]: can you help with this? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 09:25, 6 August 2023 (UTC)
:@[[User:Audiodude|Audiodude]]: can you help with this? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 09:25, 6 August 2023 (UTC)
::I think the solution is to add "extra" categories into the ReleaseVersionParameters hidden template on the [https://en.wikipedia.org/w/index.php?title=Category:New_Zealand_articles_by_quality&action=edit New Zealand articles by quality page]. See [https://en.wikipedia.org/w/index.php?title=Category:Canada-related_articles_by_quality&action=edit Canada's page].
::Then, I think the Draft category will be added the next time the bot runs, and if since you have pagesw in the "Category:Draft-Class New Zealand articles], they should start showing up there.
::Intuitive, right? [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 07:45, 12 August 2023 (UTC)

Revision as of 07:45, 12 August 2023

Proposal: Reclassification of Current & Future-Classes as time parameter

Wikipedia:Content assessment#Non-standard grades currently allows WikiProjects to use "Current-class" and "Future-class" ratings. Nothing stops an article about 2024 Summer Olympics from C-class and Future-class simultaneously, yet under the current system only one could be assigned. (WP Olympics or any other WP on its talk page do not use Future-class, so all of them classify it as C-class, but you get the point.) "class" ratings are typically based on the quality of article (or the type of page in case of non-articles). These two classes also break this very uniform format of assigning class ratings, and presents a difficulty to enact the consensus to make quality assessments global. Hence, it is my proposal to split these two classes into a new parameter |time=, where WPs can now set |time=Current and |time=Future, while simultaneously being able to set quality-based classes. This will be a gradual change. First, the code will be written out, then a bot will reassign |class=Current to |time=Current, and |class=Future to |time=Future. No manual labour will be required to implement this change, and interested projects will retain the time-based categorisations. CX Zoom[he/him] (let's talk • {CX}) 20:30, 1 July 2023 (UTC)[reply]

Survey (Current & Future-Classes)

  • Support as proposer. CX Zoom[he/him] (let's talk • {CX}) 20:30, 1 July 2023 (UTC)[reply]
  • CommentWP:USRD/et al. use Future-Class for highways not yet open to the public. The projects use a content-based system in assessing articles in addition to looking at other measures of quality. Some of that content is hard to write/source until a highway has been opened, so it doesn't make sense for us to assess articles on unopened highways the same way. The projects have opted out of the common assessments, so as long as this proposal wouldn't prohibit the continuing us of Future-Class, we wouldn't care what the result is. Imzadi 1979  22:21, 1 July 2023 (UTC)[reply]
  • Oppose. We (WP:ESC) use "future class" for events that have not yet happened. It feels weird to assign them a class when they are still experiencing major edits and expansions, sometimes weekly. Any rating like stub or start can quickly become out of date. Having future class is a reminder to go back and check when the event is over and provide the "final" class assessment. This has worked well for us for probably a decade now. Now I understand that |time= could also serve that purpose to some extent, but my take is that these articles are changing too rapidly to be able to ensure accurate or up to date class assessments. Grk1011 (talk) 23:30, 1 July 2023 (UTC)[reply]
    As you said, "Future" categorisation will be retained, just split away from class parameter, so it should not break the workflow of your project. Also, does prohibiting class assignment based on "Future" status work? If an article is assigned "Future-time", it will not be categorised under any class. Some projects use a similar approach for B-class assignment, where simply setting B=yes doesn't work, but each of 6 B-class criteria have to be set to yes. CX Zoom[he/him] (let's talk • {CX}) 06:21, 2 July 2023 (UTC)[reply]
    I would be interested in having a future label as long as it doesn't allow for a class rating to be set. Maybe that could be WikiProject-specific, but I don't speak for all of the WikiProject. As I described above, I feel uncomfortable assigning a "grade" to something that changes frequently and would prefer to wait until the article is no longer about a "future" event to assign a final class rating. Grk1011 (talk) 14:39, 2 July 2023 (UTC)[reply]
    @Grk1011, would it ever be useful to you to see that most of the "future" articles are stub-length, or that most of them are moderately well-developed? If that would be useful, then you'd want the system to accept both |class=stub and |time=future. Otherwise, I think it's pretty straightforward to make |time=future make the |class= parameter be ignored (exactly like all unknown/fake parameters automatically get ignored). WhatamIdoing (talk) 16:22, 7 July 2023 (UTC)[reply]
  • An interesting idea and thanks to CX Zoom for bringing this up. To clarify my understanding, you are proposing to add a |time= parameter to certain WikiProject banner templates (e.g. Template:WikiProject Eurovision) which would then allow them to opt-in to the standard quality assessment scale while still tracking the future/current/past status of their articles? This sounds promising. In general I support separating status-type assessments from quality-type assessments. Could we at some point also rename the categories so they are not of the XXX-Class format? Please see also my parallel proposal to rename the non-article classification categories. — Martin (MSGJ · talk) 12:38, 2 July 2023 (UTC)[reply]
  • Support – I agree that there is no reason that an article shouldn't be able to be, say "C-class", and also "Future-class", at the same time. As to Imzadi 1979's point, I don't see it as a big deal if an article were both "Stub-class" and also "Future-class" (indeed, that would likely be the case most of the time). But I also agree that "Future-class" without C/Start/Stub(/etc.)-class should be an allowed option for some WP's – so long as the system is implemented that way, it's fine. --IJBall (contribstalk) 15:47, 2 July 2023 (UTC)[reply]
  • Separating status assessments from quality assessments is a cool idea, but the devil is in the details. Assessment tables (aka "WP1.0 tables") are central to many WikiProject workflows, but those tables have only two dimensions: quality and importance. If we add more dimensions, like "time", or "type" (e.g. List which was raised a few months ago), assessment info can no longer be shown in one table. At best, we would need multiple tables (quality by importance, type by importance, time by importance). I don't think that's worth it unless we figure out a better way. DFlhb (talk) 18:04, 2 July 2023 (UTC)[reply]
  • I'm not sure about this change. The point of both fields, when in use, is presumably to mark an article whose quality (especially with regards to coverage and depth) is liable to significantly change due to expected real-world events. If being used for that, I don't see why you'd want it to for example say B-class at the same time, as that preserves the potentially outdated assessment the current/future classification is trying to avoid. CMD (talk) 01:45, 3 July 2023 (UTC)[reply]
  • This is definitely an intriguing proposal, but with that said I would also have some concerns about this change. I concur with a lot of what Grk1011 and Chipmunkdavis has said; within WikiProject Eurovision having a future-class within the class structure is very useful for keeping an eye on which articles are going through rapid expansion and change, and given the nature of how the articles under our remit come about there is sometimes a long gestation period followed by a lot of change within a short space of time (e.g. Luxembourg in the Eurovision Song Contest 2024 has already begun development and will not reach "completion" for another 10 months, with a lot more development expected in 2024). Separating the class from the time-period in this case would be an issue as a stub could very quickly turn into a C-class or B-class article in this scenario. I am willing however to hear more about how this proposed change would work in practice (e.g. DFlhb's point around how assessment tables would work with this additional field). Sims2aholic8 (talk) 08:45, 3 July 2023 (UTC)[reply]
  • Support in principle, though there may be devil in the detail. Particularly keen if it is needed to facilitate global quality assessments. My leading project interest is WikiProject New Zealand – see New Zealand Wikipedians' notice board#Discussion at Wikipedia:Content assessment for my thoughts on the proposal, with application to that project. Nurg (talk) 01:41, 12 July 2023 (UTC)[reply]
    From what I understand in your comment in the referenced discussion, I think you don't see a need for the New Zealand WikiProject to use the Future class (which of course it doesn't have to)? Also, it doesn't seem like the project needs a time parameter? isaacl (talk) 03:33, 12 July 2023 (UTC)[reply]
    Yes, personally I would do without the Future class at WP:NZ, and I'm not aware of any need for a time parameter. But I have never discussed it with others, or seen any discussion, about it. I've just assumed that because one or more editors use the Future class, they perhaps would like to keep it. Nurg (talk) 05:38, 12 July 2023 (UTC)[reply]
    Just trying to clarify if you have specific cases in mind where a new time parameter could be used. Thanks for the info. isaacl (talk) 16:19, 12 July 2023 (UTC)[reply]
  • Partial support I'd support having it an extra optional parameter so the class rating can be set as well (not sure if "time" is the best word, but can't think of something better myself, maybe "status"), but would also be good for projects that make use of it as a class rating to be able to continue to do that, as above, so I don't really support a bot doing a mass change at the moment. That of course opens the issue of having for instance class=future and time=current being set on the same article on the same project, which isn't ideal... -Kj cheetham (talk) 20:57, 16 July 2023 (UTC)[reply]

Discussion (Current & Future-Classes)

  • I will notify each of the WikiProjects which use Current and/or Future-Classes to participate in this discussion. Will let you know, when that is done. Thanks! CX Zoom[he/him] (let's talk • {CX}) 20:30, 1 July 2023 (UTC)[reply]
    Done. CX Zoom[he/him] (let's talk • {CX}) 07:21, 2 July 2023 (UTC)[reply]
  • This also opens up the issue of what happens regarding the past. Should there be parameter values for other time periods? NoahTalk 21:02, 1 July 2023 (UTC)[reply]
    Currently, it does not exist, but if we get the |time= parameter and a WikiProject wants to opt-in for past because it may help in their organisation, they should be able to. CX Zoom[he/him] (let's talk • {CX}) 21:36, 1 July 2023 (UTC)[reply]
    What I was thinking was different parameters for various past periods. NoahTalk 21:43, 1 July 2023 (UTC)[reply]
    I'd assume this is possible, although I'd defer to @MSGJ on that matter because he's the one doing all sorts of technical implementations now. CX Zoom[he/him] (let's talk • {CX}) 21:46, 1 July 2023 (UTC)[reply]
    I think it would be up to each separate wikiproject on what they wish to track. I don't necessarily think it should be within the scope of this page, which is primarily about the quality assessments of articles. — Martin (MSGJ · talk) 12:40, 2 July 2023 (UTC)[reply]
  • If adding "future" and "current" options, then I do think "past" should also be implemented for tours that have concluded as it would otherwise feel like an incomplete idea, but am not sure about breaking it down into different time periods in the way Hurricane Noah mentions. Having three different options feels like a simpler thing to work with. SNUGGUMS (talk / edits) 14:13, 2 July 2023 (UTC)[reply]
  • I feel we should be cautious about introducing a new field if there is no demand by any WikiProject for its use, independent of flagging that an article is unsuitable for a content assessment rating due to its subject being too far into the future for a stable assessment. I think it may be an ineffective use of time for editors to flag all articles as future, current, and other values when nothing is planned to be done with this information. isaacl (talk) 17:04, 2 July 2023 (UTC)[reply]
    While sending mass messages to WikiProjects through lists of Current & Future-Class categories, I have realised that most are inactive, with no discussion at talk pages for over a year or two, their empty or outdated categories also reflect this. But some WPs, mainly the roads & climate related ones are very active with their use of Future & Current classes. So, there needs to be some arrangement for them. CX Zoom[he/him] (let's talk • {CX}) 17:15, 2 July 2023 (UTC)[reply]
    Yes, but since they're not the ones proposing this change, their current needs are met by the current setup. I'm not clear who is going to use an independent time parameter. I appreciate the theoretical desire to have an independent field, but from a practical standpoint, if no one's going to use it independently from the class assessment, I think editor effort may be better spent elsewhere. isaacl (talk) 17:19, 2 July 2023 (UTC)[reply]
    I agree that for the project's I'm involved in, our needs are already met with the current setup. I understand that there could be a slight benefit, but the need for this is lacking from this discussion. As a reminder, there are also banners that can be used to indicate time concerns: Category:Temporal templates. Grk1011 (talk) 17:46, 6 July 2023 (UTC)[reply]
    If we end up doing this, I think it should only be enabled for groups that request it, which inherently excludes groups that are too inactive to make a request. WhatamIdoing (talk) 16:24, 7 July 2023 (UTC)[reply]
    It being "opt-in" sounds sensible to me. Maybe in a few years after that could revisit. -Kj cheetham (talk) 21:00, 16 July 2023 (UTC)[reply]

Can Anyone help Review my page?

I created a page for the incumbent member representing badagry of lagos, i will love anyone of you to go through the page and check. Please do tell me what you feel. PS. I am just getting accustomed to the Wikipedia UI However, I will need you to help me review the page, in other for the owner to occupy digital presence. Thanks in anticipation! Amalgoni (talk) 22:21, 6 July 2023 (UTC)[reply]

@Amalgoni, I think that you might find this UI approach to be more accessible: https://en.wikipedia.org/w/index.php?title=Draft:Oluwaseun_Sesi_Whingan&veaction=edit
When editors complain about promotional language, they mean that sentences like "Whingan has dedicated himself to making a positive impact on society through his charitable endeavors" or "Whingan is a dedicated humanitarian known for his efforts to improve society" are not culturally appropriate (in their cultures). Instead, they want you to write more things like "He worked for <name of organization> from 2014 to 2019" or "The foundation gave ₦10,000,000 to orphans in 2022."
If you aren't in touch with other Nigerian editors, I recommend finding them. There's a great group of people in Nigeria, and they hold editing events and training sessions regularly.
Finally, you need to reply to the question at User talk:Amalgoni#Paid editing as soon as possible. The acceptable responses will be honest, clear, direct, and unambiguous, like one of these:
  • "Yes, editing Wikipedia is part of my job. Please let me know what the rules are around that" (we have rules for everything, so of course we have rules about paid editing), or
  • "No, absolutely nobody is paying me at all, in any form, to edit Wikipedia. Nobody has asked me to create any pages, to add any information, or to build a digital presence on Wikipedia for anyone. I am writing this purely in my own time and at my own expense, as a volunteer".
WhatamIdoing (talk) 16:53, 7 July 2023 (UTC)[reply]
Thanks for this information, i gladly find it more relevant and helpful. I will reference to the links attached and learn more. People like you makes the community vibrant. Thanks! Amalgoni (talk) 01:01, 8 July 2023 (UTC)[reply]

Guideline template

This has the editing guideline template -meant for article editing- though it isn't exactly a guideline for editing articles per se. The article grading criteria can act as guidelines for editing, but does that justify the usage of the template? N7fty (talk) 17:54, 8 July 2023 (UTC)[reply]

Adjustment for New Zealand project

At User:WP 1.0 bot/Tables/Project/New Zealand, drafts show as class "Other", and the label "Other" does not link to Category:Draft-Class New Zealand articles, though the cat exists. Is there a way to change "Other" to "Draft" and make a link? Also, https://wp1.openzim.org/#/project/New_Zealand/articles?quality=NotA-Class&importance=NA-Class has quality "---" and "Draft" is not on the pull-down list - can it be added? See Wikipedia:WikiProject Canada/Assessment for an example of Drafts being so labelled. Nurg (talk) 09:01, 6 August 2023 (UTC)[reply]

@Audiodude: can you help with this? — Martin (MSGJ · talk) 09:25, 6 August 2023 (UTC)[reply]
I think the solution is to add "extra" categories into the ReleaseVersionParameters hidden template on the New Zealand articles by quality page. See Canada's page.
Then, I think the Draft category will be added the next time the bot runs, and if since you have pagesw in the "Category:Draft-Class New Zealand articles], they should start showing up there.
Intuitive, right? audiodude (talk) 07:45, 12 August 2023 (UTC)[reply]