Wikipedia talk:Wikipedia Signpost/Newsroom

Add topic
Active discussions


Proposed COI policyEdit

It is somewhat surprising to me that the Signpost does not seem to have an official editorial policy regarding conflicts of interest among editors and contributors. While it has certainly been our practice (at least most of the time) to proactively disclose potential entanglements with what we write here, it seems like there is no good reason not to at least have a few paragraphs about it in the About page. Here is what I have come up with:

Proposed policy

As an encyclopedia, Wikipedia's mission is to provide the public with articles that summarize accepted knowledge, written neutrally and sourced reliably. Readers expect to find neutral articles written independently of their subject, not corporate or personal webpages, or platforms for advertising and self-promotion. While the Signpost is not an encyclopedia, and its content is not bound by the same standards that govern mainspace Wikipedia articles, it is still important for our publication to maintain a high standard of editorial integrity. We do not accept payment in exchange for favorable coverage, and we believe that our contributors should disclose any potential conflicts of interest before writing for the Signpost.

A conflict of interest exists when a contributor has a personal or financial stake in the subject of their article. For example, a conflict of interest would exist if a contributor was writing an article about arbitration proceedings they were a party to, a discussion in which they participated, a company they work for, or an initiative they support.

If you believe that you may have a conflict of interest in an article you would like to write, please disclose this to the Signpost's editorial team before pitching the article. We will then work with you to determine the best way to proceed.

Contributors are expected to make pre-emptive disclosure regarding conflicts of interest. Additionally, if editorial staff become aware of a conflict of interest that has not been disclosed, we will take appropriate action, which may include choosing not to publish the article, retracting an already-published article, reassigning the article to another writer, or editing the article to ensure that it meets our standards of neutrality and impartiality.

As Signpost contributors are almost all Wikipedia editors, conflicts of interest regularly come up in the course of writing articles. We understand that it is not always possible or desirable to avoid all conflicts of interest, and we are happy to work with our contributors to find solutions that allow them to write about topics they are passionate about while still maintaining our publication's standards.

Acceptable disclosures might look like the following:

  • "The author of this article participated in the arbitration proceedings, providing comments during the case request as well as the evidence phase."
  • "Note: I wrote the article that was the subject of this AfD discussion."
  • "The organization I work for is one of the participants in this project, and received a WMF grant to work on it in 2022."

If you have any questions about this policy or how it applies to your situation, please don't hesitate to contact the Signpost's editorial team.

I encourage everyone to provide feedback on this, and suggest improvements; if we can come up with a version that passes muster, I propose that we adopt it. jp×g 22:23, 3 November 2022 (UTC)

English Wikipedia's COI policy draws a distinction between actual, potential and apparent COI. I don't see this language here. It might be helpful. ☆ Bri (talk) 22:42, 3 November 2022 (UTC)
@Bri and JPxG: a distinction between actual, potential and apparent COI I think that probably makes sense for the encyclopedia COI policy, because it's enforced entirely by self-policing and peer-monitoring. But the Signpost doesn't operate in the same "self-service" manner, and it has something Wikipedia doesn't: editorial oversight.
A news source that doesn't have to expect (and, therefore, prepare) authors to self-regulate conflict minefields can be more general in its standards and more vague in its commitments. Journalistic standards would apply equally in all cases, at least in terms of disclosures and declarations, since any undisclosed conflict or bias has the same potential to negatively impact a news source's reputation and consumer confidence. Fiddly distinctions about the nature of the conflict are of no real interest to the audience. And while the editorial approach might depend on the nature and/or extent of the conflict, that's a discretionary call for editors to make on a case-by-case basis anyway. IMHO the policy should trust the editors' discretion and give them latitude to exercise it, rather than dictating to them.
So, my personal preference would be for a policy that focuses less on (possible types of) editorial remedies to conflicts. The important policy goals, as I see them, are to establish clear and absolute expectations of Signpost authors, and to make clear and unambiguous commitments to readers. Major beats would be:
  1. Authors are required to declare conflicts at time of submission, if not before.
  2. Immediately notify the editors when an undisclosed conflict comes to light that affects previous submissions, including published articles.
  3. Conflicts known to the editors at time of publication will be explicitly declared in a note accompanying the affected articles.
  4. If an undisclosed conflict comes to light post-publication, a declaration will be printed in the next issue. Further actions (retractions, revisions, etc.) are possible, at the editors' discretion.
  5. The editors may, at their discretion, reject or reassign stories if they feel the author's personal ties threaten objectivity.
  6. An editor with their own conflict must recuse themselves from oversight of any reporting on affected subjects.
Editorial discretion is the primary means by which the editors apply policy expectations to produce an end result that fulfills policy commitments. They should have sufficient leeway to make appropriate decisions, and we should be able to trust their judgement. (At least collectively, if not individually.)
More concretely, I definitely think sentences like this one could stand some tweaking:

If you believe that you may have a conflict of interest in an article you would like to write, please disclose this to the Signpost's editorial team before pitching the article.

Phrasing it as a polite request implies that it's an option for the author to either take or leave. It's not optional, and it's not a request. If someone knows there's a conflict, they must provide that information when pitching an article. And when submitting an article. And when participating in discussions about related articles / reporting. Editors need that information, and may even request further details, so they can properly evaluate contributors' reporting and ensure objectivity.
Policy is not the place to be polite, flexible, or nice. Nice is great, but a nice policy statement is a less effective policy statement. Clear, direct, and absolute statements create less ambiguity, so they're easier to both follow and enforce. FeRDNYC (talk) 14:05, 4 November 2022 (UTC)
@FeRDNYC: Wikipedia does have editorial oversight: WP:EOC, WP:EDITDISC. ––FormalDude (talk) 00:13, 5 November 2022 (UTC)
@FormalDude: The contortions those essays perform in their attempts to justify the Wikipedia model in terms that placate journalistic traditionalists are certainly impressive, but also a bit painful to watch. Personally, I don't feel Wikipedia's approach to content needs equivocation with the processes and traditions of old-world media. The fact that it operates differently is one of its great strengths, not something to be downplayed or reframed.
Still, I'm not above drinking my Kool-Aid when necessary. So, fine:
I misspoke, in my comments above, when I said that Wikipedia "doesn't have" editorial oversight. Wikipedia articles actually benefit from more editorial oversight than any other media platform in history, because everyone is an editor! (...Seriously, nobody else smells bullshit when they read that?)
The point I was actually attempting to make was that Signpost is published in a somewhat traditional-media fashion, with contributors submitting their work to the editor(s) who organize each issue. Conflict declarations can thus be made to those editors, who can then provide external viewpoints on the nature of the conflict and its consequences for the author's submission. Nothing to do with Wikipedia, don't know why I even mentioned it.
The publishers of my brain sincerely regret this error. FeRDNYC (talk) 09:23, 6 November 2022 (UTC)
So apart from the process questions being discussed above (when and how to disclose/declare a COI etc.), the rest of JPxG's draft makes great sense to me.
One term that is too ambiguous though is "support" in an initiative they support. We need something that distinguishes opinions (thinking "yeah that initiative is probably a good thing") and statements (expressing the opinion that that initiative is a good thing) from actions (doing volunteer or paid work for that initiative, being the person who proposed that initiative in the first place).
Also, I want to call out that in a community like ours that has existed for many years, often with the same set of people working in the same area for a prolonged period of time, there naturally tend to be a lot of personal connections. (This has regularly created issues in e.g. Wikimedia chapters and other formalized segments of the movement.) It can be tricky to draw a sharp line, but some connections clearly give rise to a COI (your sibling, your direct boss, yourself) and others clearly don't (person you had lunch with once). In "Recent research" I have written quite a bit about publications by people I would consider friends and acquaintances of various degrees (from "had a nice chat once" to "I have stayed at their / they have stayed at my house for a couple of days"), but I don't necessarily consider that a COI. There have been a couple of papers where I was tangentially involved by providing some input and advice to the researchers during the project (sometimes to the point where they named me in the acknowledgements, sometimes more superficially), and I might be more scrupulous in mentioning that consistently going forward. Overall, "Recent research" has always discouraged contributions from researchers writing up their own findings, even though this could increase contribution volume a lot (except of course that we feature lots of excerpts from paper abstracts).
Regards, HaeB (talk) 02:49, 12 November 2022 (UTC)
  • No administrative capacity I agree in principle but this level of complexity is a mismatch with the administrative capacity of The Signpost. Here is my best advice for anyone who wants to develop or adopt this rule:
  1. Start drafting out an application for The Signpost to register as with meta:Wikimedia user groups
  2. Set up a project page for the group
  3. Recruit members who have time to be around for regular discussion
  4. Post this draft policy on the project page, and discuss with the members
  5. Now the editorial team here will comply with the policy
I agree with the policy and want to adopt one but what is being proposed is a labor burden beyond what current volunteers are able to provide. The Signpost has for years begged for more contributors and editorial support and is not able to meet demand on that end. As an alternative development strategy to include people who want to support journalism, but who do not want to do journalism themselves, help developing governance processes like COI policy is a welcome contribution. The part that is unwelcome is asking for any additional labor from current editorial contributors. Again, yes please develop this, but do it by recruiting additional oversight labor, rather than asking for more labor from the volunteers who are already engaged.
If there were an oversight board, then there are other policies which The Signpost could adopt. For example, https://www.ifcncodeofprinciples.poynter.org/ is respectable and we already have transparent citation practices far superior to almost any other news source. Adopting policy is a good idea, but it comes at significant labor cost and we have no labor pool. Bluerasberry (talk) 15:55, 4 November 2022 (UTC)
Sorry Lane, not sure I understand this reasoning. First, just looking at the revision history of this talk page in recent months (and the resulting changes), there seems to be quite a bit of energy among the existing crowd to discuss and update norms and processes, so the labor shortage claim looks a bit dubious in that regard. What's more, even assuming that your proposal overcomes the various concerns (discussed extensively above just last month) about incorporating the Signpost as a user group and that you can recruit such an external committee that commits to meet for "regular discussion", I'm not sure every one here will regard it as "a welcome contribution" if a whole new set of process rules (as opposed to norms) will be imposed on their regular Signpost work by a committee who is unfamiliar with the Signpost's processes. Especially not if they are patronizingly told that those rules will be made without their involvement because "oh we know you are all too busy".
All that said I would agree that we could benefit from reviewing existing COI norms for journalists and don't need to reinvent the wheel here; also, we should welcome comments from readers about what their expectations are. But we don't need to add a whole new bureaucratic layer based on a newly incorporated entity for that. Regards, HaeB (talk) 06:57, 7 November 2022 (UTC)
@HaeB: I will simplify my position: I feel that adopting this policy is a significant burden, and that volunteers here are unable to continuously give more with nothing in return. The Signpost cannot continuously adopt new policy, and adopting this policy comes at a high cost. Yes, I recognize that volunteers are interested in improving quality here, including for the issues in this policy. But committing to a policy has a high cost, and this is a negotiation which asks for a lot but brings no benefit to the table in return.
I agree that the policy is nice but if no one brings something valuable into the negotiation, then here's what can be offered for free: if any volunteer wants to help with this or any other issue in The Signpost, then they can if they like. I oppose all commitments to give something for nothing, especially in this context where demand is high and there are so many options for people to give something instead of nothing. If anyone wants more, then find a way to give more, or at least be proactive in suggesting how to bring more resources in rather than spend more of the already scarce labor.
This request is part of an unending pattern of asking more from volunteers here. The situation here is already unsustainable and asking for even more is not a path to the solution. Bluerasberry (talk) 20:06, 7 November 2022 (UTC)
Where are we on this? @JPxG: were you planning to update your draft based on the feedback, or would it be better if someone else takes the lead from here? Regards, HaeB (talk) 06:18, 30 November 2022 (UTC)

User group applicationEdit

For more context, ~4 weeks after the user group application was submitted, I contacted AffCom on Twitter (original tweet deleted, but AffCom response is still present). I was told that the process "involves different teams" and takes more than the 3 weeks that was provided as an estimate on-wiki. I've emailed AffCom and asked about the status of the application. Best, 🐶 EpicPupper (he/him | talk) 00:34, 25 November 2022 (UTC)

@EpicPupper: Is there any on-wiki record of the application? Bluerasberry (talk) 22:55, 26 November 2022 (UTC)
@Bluerasberry no. I believe it works on an email basis. Cheers, 🐶 EpicPupper (he/him | talk) 04:42, 27 November 2022 (UTC)
To clarify for others, this is in reference to this recently archived thread. I appreciate that we now have a bit more clarity about several of the questions that were raised there; e.g. to recap, I understand that the initial members of this user group (if approved) are anticipated to be EpicPupper, JPxG, Bri, and Smallbones. But the answers to the following two questions are still unclear to me:
Per m:Wikimedia user groups/Creation guide, as part of the application you agreed to have the Signpost bound by the "User group agreement and code of conduct", which among other things stipulates the following:
  • "You must behave transparently, including [...] providing an annual update of your activities to the Wikimedia community and the Wikimedia Foundation. You should post this report as an update on Meta-Wiki." - who is going to take on this task, and ensure that it continues to be carried out every year in the future?
  • "You must provide the Wikimedia Foundation the names and contact informations for two representatives for your user group. These representatives must agree to this agreement. Upon the Wikimedia Foundation's request, your representatives will need to provide additional information to confirm their identity. The names of your representatives may be used publicly to identify your group." - Am I correct in assuming that the two EiCs at the time of the application (EpicPupper and JPxG) will serve as these initial representatives?
Regards, HaeB (talk) 00:03, 28 November 2022 (UTC)
@HaeB hello! I'd like to clarify the relation of myself, J, B and S to the user group. The user group's "members" are all the contributors listed on the about page! The application just required emails and names from a few people, so I listed them. As for your two questions:
  • I can commit to this, and was planning to when I submitted the application. The role of "affiliations committee liaison" (which was previously on the about page, although it seems to have been deleted) was created for this purpose.
  • This is correct; if the application were to be approved, JPxG would be included as EiC and I would be as liaison.
I hope that clears it up! Cheers, 🐶 EpicPupper (he/him | talk) 00:44, 28 November 2022 (UTC)
Yes, I recently removed the "Affiliations Committee liaison" and "Technology manager" roles from the "About" page that you had added there in August without explanation (alongside a few other somewhat puzzling changes, some of which have since been corrected too, by others and myself).
As explained in the edit summary, this was because nobody from the existing Signpost team seemed to know what these are. (I had asked around on this talk page - "I'm curious about the "Technology manager" and "Affiliations Committee liaison" roles listed there - does anyone know what they refer to?" and received no reply for over two weeks.)
It's good to know that you are volunteering to write these annual reports. We can discuss more if and when the application gets approved, but I'd already like to suggest to run these (and other communications with AffCom) by the rest of the Signpost team, e.g. by posting a draft here firsts. Again, I'm very happy you are back on Wikipedia and I don't want to dwell on the past more than necessary, but as someone else reminded us recently, you have at times shown a problematic tendency to speak on behalf of the entire Signpost when you shouldn't have (even before your co-EiC tenure, in that controversial "From the team" piece - I stayed out of that controversy at the time, but you were definitely not speaking for me either there, and in the time since then I have begun to wonder if there were lessons learned from it or not).
Regards, HaeB (talk) 05:49, 1 December 2022 (UTC)

Publication date for DecemberEdit

I've always been a stickler for maintaining a regular publication schedule. It lets our readers know when to look for us. Maybe reading The Signpost might even become a favorite habit for a Sunday evening (depending on the time zone). Emergencies and similar excepted, of course. But December has usually been different. The week between Christmas and New Years Day is an especially difficult week to publish in - but only on the first 2 and the last 2 days. Let's get a reading on which of the 3 middle days people here prefer. Most people are taking time off from work or studies, so it doesn't matter to me, schedules are usually easy for most people, even if they are already disrupted. But I'll say Wednesday, Dec. 28, just to get this started. Smallbones(smalltalk) 19:13, 27 November 2022 (UTC)

I personally prefer the 28th or the 29th. 🐶 EpicPupper (he/him | talk) 20:02, 27 November 2022 (UTC)
Would it be too ridiculous to do a half-issue on the 15th or so, and then a half-issue on January 6th or so? We've been having big issues, and I think people would understand a split issue given the holidays. Gives us a chance to get breaking news out, and hold back anything non-urgent/Non-Christmassy for later. Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 20:51, 27 November 2022 (UTC)
As Benjamin Franklin once said about the Signpost -- "A two-week publishing schedule, if you can keep it". I think it would be good, but quite difficult; some more improvements to our workflow may help in this regard. Who knows, maybe we can pull it off. I am certainly for giving it a shot. jp×g 21:33, 27 November 2022 (UTC)
I think the important thing to remember is that it's a lot less of a deal if we hold something back when the next publication is relatively close. So if you need the whole month, focus on the later deadline, if you're able to get it out earlier, go for the earlier one. We don't need to do everything every two weeks Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 00:27, 28 November 2022 (UTC)

FYI: Mastodon accountEdit

Hi all,

to go with the times, I have asked Legoktm for an invite to create a @WikiSignpost account on https://wikis.world/ , which appears to have become a somewhat popular Mastodon server for Wikimedians. (As discussed back in February, it would be best to have a credential handling system in place, and to regain access to the wikisignpost Gmail account as - e.g. - a common contact address for such social media accounts; @JPxG: have you been looking into the latter? But also, this shouldn't hold us up for years, and in any case we have since clarified credential handling a bit as part of the EiC continuity norms. I'll use my own wikimail address for now and share the password with JPxG and the other folks who are listed as having Twitter access at Wikipedia:Wikipedia_Signpost/Newsroom/Coordination#Outreach_Manager.)

PS: Personally I've been highly skeptical of all the recent claims about the impending death of Twitter (but would love to read an article about them like this one...). However, supporting and being present on the Fediverse is worthwhile in itself. (For @WikiResearch I already set up a Mastodon account some years ago, with automated crossposting from our Twitter account - will do the same for @WikiSignpost.)

Regards, HaeB (talk) 23:48, 27 November 2022 (UTC)

@HaeB during my time we established signpost.eic@toolforge.org as the central email. It currently forwards to JPxG and I, but that can change easily. I chose this solution as it's powered by Toolforge, which is hosted by the WMF. Because of how it works, if JPxG and I both vanish/bus factor, access to it can still be recovered by making a request to the Toolforge project standards committee.
On another note, the text after "signpost." can be changed to anything, and it'll still forward: for example, signpost.outreach@toolforge.org would forward to the same people. The EiC email was (is?) used for User:The Signpost so that the email button email(ed/s) (both) EiC(s). 🐶 EpicPupper (he/him | talk) 00:36, 28 November 2022 (UTC)
Thanks for this information! Good point regarding bus factor, but for that to work, this email address would need to be known to the rest of the team in the first place. I have added it to the credentials documentation, but that is really the responsibility of the EiC(s) per our recently adopted EiC continuity norms. Regards, HaeB (talk) 06:46, 29 November 2022 (UTC)
@HaeB could you please clarify what you mean by this email address would need to be known to the rest of the team in the first place? Thanks! 🐶 EpicPupper (he/him | talk) 17:11, 29 November 2022 (UTC)
Sure, I had somehow thought this was obvious, but to spell it out: I understood your point that if the EiC(s) vanishes/vanish, the rest of the team would be able to recover the credentials from the Toolforge team. That's good thinking. However, since we wouldn't even have known that this new Toolforge address had replaced the long established official wikipediasignpost Gmail address (which we had discussed repeatedly here and over email earlier this year, IIRC without you ever mentioning that you had already "established signpost.eic@toolforge.org as the central email" instead), we - the rest of the team - also wouldn't have known that we could ask the Toolforge team to get access. Does that make it clearer?
Again, I really appreciate you providing all this information now, and I don't want to dwell on the past more than necessary. But it seems worth stating directly that is among several things that could have been handled significantly better during your now concluded co-EiC tenure. Regards, HaeB (talk) 07:01, 30 November 2022 (UTC)
@HaeB thank you for the clarification. 🐶 EpicPupper (he/him | talk) 23:05, 30 November 2022 (UTC)
@HaeB:
  • My apologies that the Toolforge email was not discussed on wiki; I recall mentioning it with JPxG off-wiki. Here, I see that I posted Mailing list: I'll try to coordinate creating a editors@signpost.news and use that for mailing list announcements., but I was met with silence on the matter. There may have been a follow-up clarifying the current Toolforge situation, but I do not recall. Ultimately, I feel that the many Signpost improvement projects (see that page for I pursued led to difficulties in communication and organization, and I regret that it happened.
  • "About" page and puzzling changes: I have no objections to the role of technology manager being removed. The Affiliations Committee liaison was intended to be the point of contact for AffCom and The Signpost, but if it is preferred by the current team to not codify this, I will respect that.
  • User group application: I hope that the aforementioned statement of [my] problematic tendency to speak on behalf of the entire Signpost when you shouldn't have does not include the events surrounding the user group application. I previously discussed the recognition idea without objection. This was after I observed previous musings about affiliation recognition that were generally positive. Also see the various "14 days", "7 days", "3 days" until publication, etc. threads; for example, on the one linked above in the first bullet point, I discussed the user group application yet again (also with no comments).
  • ANI thread: If I am not mistaken, I believe that the vast majority of Signpost contributors supported the editorial. I posted my justification, the process that produced the piece, and more clarification in the thread; that may be relevant here. Please let me know if you have any further questions about the piece.
  • I wish to express that the newly-passed "continuity norms" for EiCs should be clear in the distinction of expectations between Editors-in-Chief and co-Editors-in-Chief. I feel that it should be considered if a period of activity would be less impactful, should there be another current EiC also responsible.
I apologize for my shortcomings in communication and any confusion it may have caused. 🐶 EpicPupper (he/him | talk) 17:35, 1 December 2022 (UTC)
OK, I have set up https://wikis.world/@WikiSignpost (including crossposting), reached out via email to the folks who are listed as having Twitter access (@JPxG: for you I used the eic email address that EpicPupper revealed above, let me know in case that didn't work), and updated the credentials documentation at Wikipedia:Wikipedia_Signpost/Newsroom/Coordination#Outreach_Manager. Regards, HaeB (talk) 06:46, 29 November 2022 (UTC)

feeder readbackEdit

all posts are at Wikipedia talk:Wikipedia Signpost/Single/2022-11-28... perhaps less clumsy than the relatedchanges one. Let me know what you all think of it. ,jp×g 16:44, 28 November 2022 (UTC)

Or the old fashioned wayBri (talk) 17:04, 28 November 2022 (UTC)
Bri's version catches all comments. JPxG's version misses Wikipedia talk:Wikipedia Signpost/2022-11-28/Book review, Wikipedia talk:Wikipedia Signpost/2022-11-28/Opinion‎, and Wikipedia talk:Wikipedia Signpost/2022-11-28/Tips and tricks‎‎ Headbomb {t · c · p · b} 16:56, 30 November 2022 (UTC)
Hmm. Well, the way my version works is to automatically pull the issue's articles from Module:Signpost -- if they haven't been added to the index page, they won't show up on the single comments page. Right now, this relies on people going through the issue manually with SignpostTagger, which means it is not an ideal solution (at least not for a few days after publication).
The obvious solution is to integrate some functionality into the Signpost Publishing Script that collates JSON data for the issue and automatically adds it to the module's index, although this requires someone (probably me, although I would certainly be thrilled if someone else figured it out) going through SPS to figure out what is going on under the hood. jp×g 23:32, 1 December 2022 (UTC)

"Concept" column in next issueEdit

Sorry for snipping WP:Wikipedia Signpost/Next issue/Concept accidentally from the in-progress articles during the Newsroom reset.

This piece seems a little problematic, not really fitting into the usual Technology report. If it was proposed somewhere like WP:VPT, we could list it in a Discussion report. I'm not really sure that a Signpost article is the best place to roll this out. Also, isn't the idea just an implementation of Run-length encoding (I'm sure this would have been brought up at VPT). ☆ Bri (talk) 20:06, 28 November 2022 (UTC)

Honestly, with the move to "Next next issue" it was probably inevitable. But I think it's reasonable to propose such things publicly to get more discussion. We're not a commercial newspaper, we don't have to have every article be a high-engagement article for everyone. Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 21:07, 28 November 2022 (UTC)
Looks like the talk page got lost in the move: Wikipedia talk:Wikipedia Signpost/Next next issue/Concept.
In addition to the concerns raised by Bri, the writing and presentation in the main part (i.e. below the intro added by Adam) are honestly terribly convoluted. E.g., to name just a small example, why are there tables that present the same number repeatedly in slightly different formats (e.g. "17449299" under "Count" vs. "17 449 299" under "Human-like count")?
Also, does anyone understand the author's responses in the "Existing 'ez' compressed format, as well as pageviews complete" thread, where Milimetric (WMF) stated that the proposal is mostly redundant to an existing dataset?
Regards, HaeB (talk) 06:41, 30 November 2022 (UTC)
I'll withhold comment on the idea itself, but yes it is exactly a particularly naive form of RLE (as it only compresses runs of one specific character pair: 0 ). I don't see any reason why a Signpost article would be the right venue to propose generating pageview dumps in such a scheme. If it were adopted by the Data Engineering team, then an article explaining how the new format was arrived at and why it's of interest to Wikipedians might be appropriate. (With far less technical detail, that stuff's for the wikitech site.)
@HaeB: Basically he's doing an apples-to-oranges comparison, and saying that even though the pageviews_complete 'ez' encoding is far more efficient than his format for daily or monthly data dumps (not that it's acknowledged out loud, but it's true so it doesn't have to be), his format can encode hour-granularity yearly dumps more efficiently than actually writing out 8760 repetitions of 0 for low-traffic pages. While that's true, it's begging the question to assume that anyone wants combined yearly per-page view stats at hourly granularity. And that if they do, they want them in a byzantine format like (to take a real-world example from one of the en.wiktionary datasets I downloaded):

"qué_duda_cabe" 8082839 desktop ^2941 1 1 ^5817

That signifies, "obviously", that the page wikt:"qué duda cabe" (id 8082839) received a single page view from a desktop-browser visitor on the 2942nd hour of 2021 (which I determined, by whipping out the Python arrow module, was:
arrow.get('2021-01-01').shift(hours=2942) ⇒ <Arrow [2021-05-03T14:00:00+00:00]> ...May 3 at ~14:00 UTC), and then a second page view in the following hour.
Now, you may be thinking, "OK, that's efficient, but for a page with that little traffic you could just write out the date of each individual page view and it wouldn't be much longer." And you'd be right! In fact, that line represents a re-encoding of a line from the pageviews-20210503-user file that would've read something like,

en.wiktionary "qué_duda_cabe" 8082839 desktop 2 N1O1

(N being the 14th letter of the alphabet, and O the 15th), as that's how the efficiently-encoded daily pageview files are already formatted. That format doesn't store date information in the data, it's left to be implicit in the filename of the data dump. The article in question wouldn't appear in any of the other 2021 daily dump files, as it didn't have any views any other days.
Of course, if you only wanted to follow that one article, you wouldn't use the data dumps. You'd likely make a query to the pageviews API, which would return this data:
{
  "items": [
    {
      "project": "en.wiktionary",
      "article": "\"qué_duda_cabe\"",
      "granularity": "daily",
      "timestamp": "2021050300",
      "access": "desktop",
      "agent": "user",
      "views": 2
    }
  ]
}
The API only supports daily or monthly granularity, so whether hourly is even needed... ¯\_(ツ)_/¯. FeRDNYC (talk) 07:05, 1 December 2022 (UTC)

Featured contentEdit

I've roughed in the December issue; everything except the summaries for five articles and my introductory paragraph. If we are doing two issues, given we work a month behind, probably not a bad idea to have it early. Unless there's more content promoted (outwith FPs) on the 30th, it's done. Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 20:46, 28 November 2022 (UTC)

Archiving November newsroom talkEdit

Can I get some guidance on what to keep on this page from November? I think there was some part of pulled back from the archive last month. Just don't want to over-archive again. ☆ Bri (talk) 17:47, 29 November 2022 (UTC)

You know, I wonder if it wouldn't be easier for us to just do the archives by month. It would create some doscontinuity, but it would be a hell of a lot easier to deal with. jp×g 20:12, 29 November 2022 (UTC)

I don't think anything above the discussion of the next publication date matters anymore. Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 21:07, 29 November 2022 (UTC)
I have un-archived two that shouldn't have been archived yet. Please respect that not everyone is active here every day, so the fact that there were no responses in a thread for like two days does not mean that it has concluded. And as discussed before, given how frequently manual archiving has created problems on this talk page over the course of this year, I am strongly in favor of just letting the bot do this work, even if that wouldn't fully satisfy the desire to minimize the current number of sections.
Alternatively, we may want to start respecting the talk page headers again ;) - to viz:
  • This page "is to discuss the upcoming issue of The Signpost."
  • Wikipedia talk:Wikipedia Signpost is "for general or technical issues, praise, queries, or complaints related to The Signpost as a whole."
That may help to separate the timely discussions about specific stories from the slower-moving general topics like the COI policy or user group conversations. It seems that we all (myself included) have slipped into instead treating this page as the default location for all Signpost team discussions, and Wikipedia talk:Wikipedia Signpost more as an externally facing reader forum, but I am not sure that distinction makes much sense.
If there are no objections, I may start to occasionally move newly posted threads to the more appropriate one of these two talk pages, as per the existing header descriptions.
Regards, HaeB (talk) 06:14, 1 December 2022 (UTC)
Sorry. I didn't expect to be the only voice deciding. Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 13:10, 2 December 2022 (UTC)

Translations?Edit

I write texts about Wikipedia on a fairly regular basis, for Swedish magazines, newspapers and other outlets. Some of these are not relevant for Wikipedians (they are meant explain things for outsiders), others are irrelevant outside of a Swedish context, but some could potentially be of interest to The Signpost, if translated and adapted. Would the occasional translation of material previously not available in English be of interest?

For example, I'm thinking of an article which I figure could fit the serendipity feature, about when I realized the painter of some art I just bought might have been a functionary in a Swedish Nazi party in the 1940s, and then spent a year – or around a hundred hours, spread out over a year – to get to the point where I could update his Swedish Wikipedia article with a couple of sentences. A light-hearted example of how bizarre amount of work sometimes leads to rather small edits. /Julle (talk) 07:22, 30 November 2022 (UTC)

Response to suggestion pageEdit

I suggested that JamieF go forward with her suggestion, "the View it! tool, a new tool for discoverability of images on Commons in development utilizing Structured Data on Commons." It sounds to me like it should be part of a a Signpost Technology report article, unless it gets really long then it can be stand-alone. ☆ Bri (talk) 16:57, 1 December 2022 (UTC)

Wikipedia:Wikipedia Signpost/Next issue/Featured contentEdit

I think this might be my most "meta" introduction, as it explains exactly how the sausage is made.... Adam Cuerden (talk)Has about 8.2% of all FPs. Currently celebrating his 600th FP! 18:52, 1 December 2022 (UTC)