Idea for collecting "Cool New Features / Cool New Packages" article ideas

Continuing from the devel list post: Re: How do we announce new packages? - devel - Fedora Mailing-Lists

Quick summary of discussion:

  • There doesn’t seem to be a good way for people to learn about new packages added to Fedora Linux or other small features that aren’t changes and might not even be linked to a release.
  • A new mailing list was proposed, but I think the Magazine would actually be a better venue — I don’t think a significant number of the right audience would sign up for such a list, and the Magazine audience is the right audience.

So, how can we collect these things for the magazine? Ideas include

  1. A separate pagure tracker where people could enter suggestions for some group to eventually propose a magazine article for
  2. We could have special tags in the :category_workflows: Team Workflows: Magazine category like #new-package #new-feature which people could use instead of a regular article proposal, and these would be periodically collected into articles — with the magazine editorial team taking a more active role in making sure the collected articles get written
  3. We could have a Fedora Chat room where people would post topics, and topics with a certain amount of reactions would get automatically collected every month and posted as an article idea here. (Inspired by This Week in Matrix).
  4. Something else?
1 Like

FWIW, idea number two sounds pretty reasonable to me. We could search for that tag to get an ordered listing of new packages. People could easily tack notes onto the initial posting. An editor could close the thread to mark the ones that have been published.

1 Like

Hello @mattdm ,
I would have to agree with @glb that number two would be more inline with current Editorial workflow, and would also allow the editors to control the release of the info, say on a cycle that falls outside of the Fedora Linux official release cadence. Possibly offset from the COPR announcements. Raising awareness of the cool new things packaged in Fedora Linux is a primary role the Magazine should play I think.


I see two problems with option 2:

  • Who is actually going to curate and collect ideas and actually write the articles?
  • I already find discussion.fp.o very chaotic, hard to “grok” and navigate, especially when compared to a single-purpose ticketing project on pagure (option 1).

I think the workflow with option 1 (pagure ticketing project) actually aligns better with the current packager workflow. Most of us are used to opening pagure or RHBZ tickets for various stuff (be it bug reports, releng, infra, fesco tickets, etc.). The “curators” can then collect proposal tickets, mash them together, and then actually propose a magazine article.

1 Like

If it is just a small listing of new packages every once in a while (similar to the “4 packages to try from the Copr repos” posts), then the magazine editors might be able to do it. If we do it though, it would probably just end up being a few package names as section titles with the output from, e.g., dnf repoquery --qf '%{description}\n' tar as the body text for the section.

I’m not opposed to using Pagure. I actually thought it was less visible than here though. If we want/expect end-users to provide any feedback on the new packages (perhaps unlikely anyway) I think that would be more likely to happen if the packages were listed here somehow.

That makes sense. Especially if the process of listing new packages is going to be manual. I was kind of expecting that the list of new packages would be automated somehow, in which case, I don’t think it would matter from the packager’s perspective which system the list was written out to. (But I could be wrong. I’m not a packager.)

It’s a change in thinking but — in my experience at least — can quickly become familiar (and I’m someone who has always hated web forums). See Navigating Fedora Discussion — Tags, Categories, and Concepts if you haven’t already, and my top tip: mark the tags you specifically care about as Watching (either by using the bell on each tag page, or in your preferences). Then set your site Default Home Page to “Unread”. Wit this, the front page view of the site will be a consolidated view of new topics just from those selected things.

I do see your point about packager workflow.

1 Like

BTW, the magazine is currently in need of content for publication. If there is some way that a “backlog” of new (Fedora Linux 35?) packages could be generated, I’d be happy to try to assemble a posting for the magazine right now.

Only taking a list of new packages and their descriptions is meaningless. As I mentioned on the mailing list, querying for “new” packages is easy, but the signal-to-noise-ratio in that list makes it useless.

Why would it need to be “visible”? The magazine articles would be getting visibility, the tickets don’t need it, unless I misunderstand what you’re saying.

I think the main benefit of “marketing” cool new stuff would actually not just be “new packages”. There’s lots of features and improvements being worked on within existing Fedora packages every day, probably way more new features get added that way than by adding new packages.

As mentioned above, I don’t think “new packages” is a worthwhile topic on its own. We’d need somebody to actually go through that list, filter out the 99% that are noise, and then figure out why or if something is worth mentioning for the 1% that remains.

… which is why I think a ticket / suggestion queue filled by the actual people who worked on new features (be that within existing packages or by adding new packages), where they can include a reason why something should be included in the magazine article themselves (instead of somebody else having to figure that out) is a good idea.

So I don’t actually know what the list of new packages would look like. I guess I was thinking it would be a relatively small list – a handful of items every few months – and that it would be “obvious” if a package was significant or not.

Yeah, if it is going to be a large list and it is not obvious if a package is directly useful to end users, then someone other than a magazine editor would need to curate the list.

Yeah … I just looked at the last 7 days (which were quite quiet due to the holidays), but still, 26 packages have been added, of which maybe one would be interesting to end users, the rest is just “low-level library update / addition churn”. On the other hand, in the same time period, there were 677 package updates in rawhide. Sure, most of those are not interesting to users either, but assuming the same 1 / 26 “signal to noise ratio”, that would still be ~26 “maybe interesting” changes.

1 Like

OK. I agree then. That’s a lot more than I expected (and I wasn’t considering “changes”, just “new” software packages). If it is going to be that much to deal with then a Pagure repo with a kanban board to manage all the content is definitely in order. Just let me know when you have something ready for publication and we’ll get it out. :slightly_smiling_face:

As it’s being noted in the latest part of the discussion, the problem is that packages could be anything, from low-level libraries to developer separating functions to an independent package. But still it works for part of my point:

Showing only retiring and orphaned packages in the devel list give the impression of less packages or less software in Fedora

And now, what I’m thinking now is what about a chart with number of packages in time? It could be less dramatic?

That’s aside of the promoting new software in the magazine, I love that idea

I don’t know how you are generating these lists, but if there is a simple way to check if a package includes a binary under /usr/bin, that might be a simple way to filter out a lot of the “noise”. Just a thought.

In this case, I looked at Rawhide compose reports from composes that were successful within the last 7 days. There’s a machine-readable JSON version of those reports, and then querying if any of the added packages ships something under /usr/bin should be possible with some scripting. But at that point, I think you’re making this more complicated than it needs to be :wink:

1 Like