I would like to contribute an article about the bpftrace tool
(overview, quick start, basic usage, etc.)...
I've just created a pitch:
Could editors please review it?
Augusto Mecking Caringi
I was wondering if any one was interested in joining me to writing a
series of "Fedora: under the hood" posts (if the editorial team permits,
of course) with the aim being to:
- show that Fedora is a FOSS community with the OS being our mode of
choice to work towards the community mission.
- discuss the work that goes into the creation of each release:
including programme management, design, rebuilds, QA, websites,
announcements---all of it.
The hope is that by speaking actively about why, who, and how we do
things, we improve the general understanding of how we tick. In
addition, that improved understanding will hopefully encourage more
"users" (to use the "vendor <-> user" terminology explained later) to
join the community and contribute to FOSS---in whatever way they choose.
Finally, it will also make people aware of the resources that the
community has or does not have access too, and why some things are done
and others aren't.
Based on my personal experiences, so this is anecdotal evidence, it
seems that most people outside the community have little or no
understanding of how the Fedora community does things. They seem to
apply the "vendor <-> user" development model to Fedora too: someone,
somewhere, for some reason, is doing all of this for "users" instead of
the "community" paradigm: where there isn't a clear distinction between
"developers" and users---all contributors are also users, and we're all
part of the community and contribute in whatever ways we can often in
our free time.
Mostly, the magazine includes posts on how to use software: "to do
things with Fedora". The new website also says "Make the most of using
Fedora" next the Fedora magazine bit. So, users get to learn about all
using the tools and the software, and not much about why, who, how, all
of this software (and the accompanying information) is
developed/integrated/provided to them.
PS: Of course, the primary aspect of the "vendor <-> user" paradigm is that
the user pays in exchange for the service. This enables the "vendor" to
maintain the resources required to continue providing the service and
further improve it. How users "pay" to use Fedora if we also follow this
model does not seem to come up often somehow.
Ankur Sinha "FranciscoD"
Time zone: Europe/London
I'd like to propose we use a Taiga kanban board to track the state of our
articles and the publishing schedule.
Having a board will have multiple benefits, including:
- Quick overview of the current state and the publishing schedule
- Writing comments to the articles — things to remember when editing, etc.
- Ability to move some of our activities from the meeting to the board,
such as +1's on the pitches, assigning edits and images, or even scheduling
in some cases — that could give us more time in the meeting for other
discussions that need to happen real-time
- A board will be also more intuitive and accessible to newcomers
What do you think? Do we wanna give this a try? To give people a better
idea I've created an example board  in the teams.fp.o Taiga.
Senior Software Engineer
There's a thread on Discussion about Magazine articles that are out
of date (e.g. due to orphaned packages). I know it can't really be
done automatically, but do we have a process for marking outdated
articles in a way that's obvious to readers? If not, what might that
He / Him / His
Fedora Program Manager
I've just republished the Packit article  that was originally published
last Friday, but had to be taken down for additional editing. I've
published it today instead of the Pantheon desktop for two reasons:
1) The Packit article is ready and I didn't want to hold it for longer than
I had to. That was convenient, because:
2) Pantheon desktop feels a bit buggy to me. I couldn't log out, some of
the settings are missing, the top-bar nearly disappears after clicking on
it, etc. Even though there are some things I really like — especially the
ability to fine-tune notifications and a "do not disturb" mode, I would
give it some more time to mature before publishing an article about it on
See you later today in the meeting!
Senior Software Engineer
userspace-containerization would like to publish an article about packit to
Here is a preview for pitch
Please let us know, what do you think about it.
Senior Software Engineer
Userspace Containerization team, Platform
Red Hat, Inc.
Mob: +420 777 056 169
There have been multiple people finding the term "auto-package" in your
article as misleading. The main concern was that packit currently doesn't
generate a SPEC file which we felt like it's a substantial part of
packaging. So I had to pull it out for additional editing.
If I get it right, once you have the spec file, it does all the work for
you, right? So maybe we could change it to "auto-update" in the title? And
clarify that in the article, too?
I understand that auto-packaging is likely the goal of the packit project,
but I personally find it a bit aspirational at this very stage. That being
said, I'd be great to get another article out once we get the SPEC file,
Do you prefer to update the article yourself, or would you rather have one
of the editors to have a look at it? I'm asking because I don't want to put
words into your mouth (like "auto-update") without asking you first. :-)
Please let me know.
On Saturday, May 25, 2019, Adam Samalik <asamalik(a)redhat.com> wrote:
> OK thanks for the feedback, I took it out and will deal with it properly
> on Monday. It'll need a new title, a new image, and some additional editing.
> On Friday, May 24, 2019, <s40w5s(a)gmail.com> wrote:
>> Magazines print retractions all of the time. It is an unavoidable
>> consequence of writing articles of factual based information, there
>> will be errors from time to time. Correction for clarification
>> purposes, even as an editorial note, is definitely in the editors
>> "wheel house" and in this case is needed in my opinion. Although I
>> don't have familiarity with the packaging process enough to dive into
>> it, otherwise I'd help more, but I can cheer Adam on!
>> On Fri, 2019-05-24 at 20:48 +0000, Fabian Affolter wrote:
>> > > I don't think I should pull it out at this point, nor should I
>> > > rewrite it.
>> > In the current state the article is misleading. It seems that we can
>> > agree that packit doesn't "auto-package".
>> > > Also, I don't want to add a note such as "Editor's note: packit
>> > > doesn't
>> > > actually generate a SPEC file for you." because that wouldn't feel
>> > > good. So
>> > > I think I just leave it as it is at this point? Any better ideas?
>> > Leaving the article as it is, is definitely the worst options. If
>> > editing "wouldn't feel good" then the article should be remove
>> > immediately. Otherwise it will stay at least online for two more days
>> > till something is done.
>> > I'm all for editing because nobody will complain about clarification.
>> > Kind regards,
>> > Fabian
>> > _______________________________________________
>> > Fedora Magazine mailing list -- magazine(a)lists.fedoraproject.org
>> > To unsubscribe send an email to
>> > magazine-leave(a)lists.fedoraproject.org
>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> > List Guidelines:
>> > https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> > https://lists.fedoraproject.org/archives/list/magazine@lists
>> Fedora Magazine mailing list -- magazine(a)lists.fedoraproject.org
>> To unsubscribe send an email to magazine-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.or
> Adam Šamalík
> Senior Software Engineer
> Red Hat
Senior Software Engineer
I did write the usual post for the begin of the submission phase for the
F31 Supplemental Wallpaper today. Would be nice it can be published,
when the phase opens. Just changing of the dates and added a line,
please stay away from submitting pets/cats. And the gallery changed.
Previously there was offline discussion to organize Magazine + CommBlog
community awards at Flock 2019. I wanted to re-surface this and see if
anyone wants to take lead on this idea for Flock 2019.
I thought it is a good engagement strategy to create community awards
for authors / editors of the Fedora Magazine + CommBlog. I took the idea
from Opensource.com with their People's Choice and Editor's Choice
awards each year. Some ideas for awards were the following:
* Top 5 new contributors of 2019
* Editor's pick: Top 10 articles
* Author(s) of the Year
* Editor(s) of the Year
Ideally, awards should be as objective as possible.
Since not everyone who contributes is able to attend Flock, we could
also give out honorary awards for people who are unable to attend, and
accompany it with a published announcement to go out on the Magazine /
The Flock CfP is now open (https://flocktofedora.org). Perhaps this
could be integrated into an evening activity or something at the end of
the conference (so an awardee who might be tied up in other sessions
would have a chance to attend and be recognized).
The first round of feedback for this idea was positive. Does anyone have
an interest in leading this event with the support of our editor teams?
Justin W. Flory