It's that time of the half-year again; we're about a month from the
current planned date for Fedora 29 final release, and it's time to start
banging out release notes.
Anyone who wants to contribute should start here:
1. Pick one or more issues that have "F29" in the title.
2. Open each issue you picked, and click the Take button on the right to
claim it. (If you claim an issue but later find out you don't have time
to write about it, remove yourself from the issue ASAP so others can see
it's free and take it!)
3. Find some information about the issue. A lot of them have plenty of
info in them already; if not, find out who's responsible for the change,
and talk to them on IRC or via mail. Of course it's always better if you
try to do research before you ask questions.
4. Write a release note about the issue. If you're not sure how exactly
a release note looks, check out some of the previous releases for
inspiration. We don't want any long, overly technical texts, the release
notes are meant to highlight changes, not tell people how to use something.
5. Now the workflow diverges based on your permissions and technical skills:
5a. If you know how to use git and asciidoc, we'd appreciate if you
wrote up the release note and sent a pull request against the main repo,
branch "f29". Note that we have a different directory structure for this
release; your contributions should go into one of the files in
"modules/release-notes/pages/". Use the "build.sh" and "preview.sh"
scripts in the repository root to preview your changes locally; see the
repository README for specific instructions. If you can't see the
section where you added your contributions at all, make sure it's
included in "modules/release-notes/nav.adoc".
5b. If the above sounds like gibberish to you, it's fine: just add a
comment with your text into the issue, and ping me on IRC or through
e-mail; I'll mark it up for you and make sure your contribution appears
in the final document.
If anyone has any questions, go ahead and ask. The current schedule
shows the preferred final release target at October 23, giving us about
a month and a half. Don't count on the release date slipping :).
Petr Bokoč (pbokoc)
Senior Technical Writer
Community Platform Engineering
Red Hat Czech, s. r. o.
612 45 Brno, Czech Republic
I am Amit Sharma from Jaipur, India.I am currently looking to contribute in
Fedora community. I have been a Linux user since 2016 but this is my first
time on intending to join an open source software project since I am
confident that I already acquired necessary skills to contribute.my
computer skills level is intermediate because I can successfully install
and configure a Linux o .s.However, I can do only basic web programming
significantly to the Fedora project is user documentation especially about
installation and configuration in a desktop and laptop and also looking
forward to learn more things with you all.
Can anyone sponsor me for the group?
The part about sudo is very out of date (we _do_ now configure sudo by
default, and have for a very long time), and the part about dnf is a mess.
The part about "using apt anyway" should be removed, since it really doesn't
The life cycle part could be written in a more positive way, and could
emphasize ease of upgrades.
There's probably more stuff. We can talk about GNOME Shell, and also about
Fedora Server and Fedora Atomic Host / CoreOS.
So, yeah, all of that, plus of course update to new docs site and put the
wiki redirect macro in place.
Anyone interested? This'd be particularly useful for someone who does a lot
of playing with other distros. (We could use similar for Mint, Debian, and
Arch as well.)
Fedora Project Leader
You are kindly invited to the meeting:
Docs Writing Hour on 2018-09-26 from 10:00:00 to 11:00:00 US/Eastern
The meeting will be about:
Join members of the docs team in #fedora-docs for writing time. This is a great time to focus on writing and talk about challenges and blockers related to producing content.
There is no formal schedule for this meeting. Attendees should show up and use this as a way to block writing time into their week.
I am regularly getting pulled into several Fedora Docs related
conversations in Telegram. These typically are around Antora and tooling,
but are occasionally around large areas like L10N and new doc components.
NO decisions are being made in Telegram, these are more working
I'd like us to consider setting up a Telegram <-> IRC bridge, like some
other channels have done so I can easily redirect these conversations into
the public eye and encourage greater participation.
What do you all think?
Brian (bex) Exelbierd | bexelbie(a)redhat.com | bex(a)pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
Currently, Fedora's community has no system of writing the documents of the technical specifications.
For example, in the manufacturing industry, the work to leave technical information necessary for design for successor designers (engineers) is are incorporated into one of the jobs .
Such documents will be referred to as technical specification or design specification etc .
Applications supplied by fedora - such as anaconda and dnf - I think that the document of the technical specifications are necessary.
For example, the definition of a function defined in each application is obvious to the designer of this application, but it takes many time for a third man to understand it.
Therefore, in IT companies in general, writing a specification document is also included in the work.
I think that, Maybe Red Hat, the main sponsor company of Fedora, would have left the specifications when developing the application.
Fedora community should write the designer's specification document as well.
Bug ID: 1629687
Summary: Valuable information missing regarding supported
devices (revision 25-0 Mon Nov 14, 2016)
Product: Fedora Documentation
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: dayleparker(a)redhat.com, docs(a)lists.fedoraproject.org
Description of problem: valuable information missing regarding supported
Expected results: at
Updated: 2018-08-23) it is stated:
' up to 216 virtio devices' and 'up to 32 assigned devices per virtual
Similar information to be provided in documentation
You are receiving this mail because:
You are on the CC list for the bug.