Hello Docs team,
I've made some updates and fixes to a few Quick-Docs files that are
ready for your review at https://pagure.io/fedora-docs/quick-docs/pull-
Let me know if there are any issues or edits that need to be made.
On 03/14/2018 04:06 PM, Geoffrey Marr wrote:
> Hey CommOps team,
> Could someone review and submit this PR against the Quick Docs pages?
Hi Geoff! I think it may be more relevant to share this on the Docs
mailing list, since more folks on this list will be familiar with the
quick-docs and the on-going work with the documentation toolchain. I
added their mailing list in this reply.
I'll try and take a look later this afternoon if someone else doesn't
beat me to it.
Justin W. Flory
On 02/25/2018 01:01 PM, Harris Kenny wrote:
> Hi commops!
> My name is Harris Kenny (kenhara). I am new to contributing to Fedora
> but have been running Fedora for several years on my personal machines.
Hi Harris! Welcome to the Fedora CommOps mailing list. We're happy to
have you here with us.
> I first learned about Fedora at Open Hardware Summit 2015, where I met
> Tom Callaway (spot). I enjoy the active community and stability of
> Fedora and have relied on its documentation as a new GNU/Linux user. I
> would love to help expand the documentation to help future new users.
> I want contribute to the Fedora Wiki because I have experience writing
> documentation. I specifically want to start by helping with
> documentation for 0 A.D. (0ad
> <https://apps.fedoraproject.org/packages/0ad>), which I recently
> discovered and love.
If you're interested in improving Fedora documentation, I would also
recommend checking out the Docs team. A lot of work is happening now to
"re-tool" the Docs team. If you are interested in updating existing
documentation or writing new documentation, I would recommend working
with the Docs team on the best way to do this.
I've also CC'd their mailing list in this reply. You can check out their
> Though this is a personal application to join commops, my professional
> work is relevant too. I work for Aleph Objects, Inc., manufacturer of
> LulzBot 3D printers. LulzBot printers are Free/Libre/Open Source, both
> the first product certified by the FSF
> <https://www.fsf.org/resources/hw/endorsement/respects-your-freedom> and
> the first printer certified by OSHWA
You may also be interested in the 3D Printing SIG in Fedora. I haven't
participated much with their SIG to know what tasks they are working on,
but you may find it interesting to check out. I also know Tom, who you
met, is a part of this SIG!
> I started in Marketing at the company, helping establish documentation,
> tutorials, email newsletters, social media, digital advertising, trade
> shows, public relations, etc. with all Free/Libre tools. Cura LulzBot
> Edition software is also packaged for Fedora (see: cura-lulzbot
> In another personal capacity, I serve as Treasurer on the Board of
> Directors at OSHWA. I have also contributed writing to opensource.com
> <http://opensource.com>, among other places.
> Besides contributions to Wikipedia, this is the first time I'm looking
> to personally contribute to an open source project (outside of work).
> I'd love any articles or tips on how to get started and avoid obvious
> new contributor mistakes :) (Bootstrapped
> <https://pagure.io/Fedora-Badges/issue/409> seems like a good start)
> Thank you for your time and consideration!
Sounds like you have a lot of experience with open source – it will be
great to have you with us!
In the meanwhile, I would recommend "getting bootstrapped". At the Docs
FAD a couple weeks ago, I created a page to help explain how to do this.
It's not officially published yet, but you may find it useful!
Let us know if you have any other questions. Hope to see you around. :-)
Justin W. Flory
Hi docs people,
It's that time in the release cycle again when your help is needed to
put together release notes for Fedora 28. (Actually the time was like a
month ago, but we still have time to produce something for beta.)
There is a number of open issues against the release notes repo on
Pagure, which is where everyone should start:
Note that 1) there's a page two, and 2) some of the issues are filed
ahead for F29, so please pay attention to what you're assigning to
1) Go to the link above
2) Identify one or more issues you want to cover for this release
3) Assign yourself to the issue (if you're logged in to Pagure using
your FAS account, there will be a "Take" button in the left sidebar when
you open the issue)
4) For issues that were created for covering Changes, there's always a
link in the description. Follow it to learn more about what you're
covering. Some issues also have additional links provided by their
owners or anyone else in the comments, check those out too.
5) Write something about the subject matter using the information you
just gathered. Pro tip: a lot of Changes involve introducing a new
version of an existing component, like a programming language, into the
next release, which means the component has an upstream version with its
own documentation including release/patch notes. In these cases, it's
good to pick a few notable changes and mention them in Fedora's release
notes, and link upstream for the rest. "For more information about this
release of Python, see <link>." Saves you a ton of work and it's still
useful to the reader.
6) Contact the Change owner(s), or in case of issues that aren't
covering Changes, contact the person who opened the issue - or really
anyone you can think of who might have some insight into the matter -
and ask them nicely to check out what you wrote and make sure it's
technically accurate. To make this review easier, I recommend doing this
through issue comments, and @-pinging people so they get a notification.
If they don't respond within a reasonable time frame (give them a few
days), try contacting them in other ways - typically #fedora on FreeNode
7) Once your contact(s) tell you your text is fine (this may or may not
take a bit of going back and forth), you have two choices:
* If you're familiar with ASCIIDoc and git, fork the release-notes
repo, mark up your text and make a merge request. Once it's accepted,
close the issue. (This might actually happen automatically during the
merge, I can't remember...)
* If you're not familiar with any of the above, just leave the final
version in the comments, and then add a tag to the issue indicating it
needs someone to do that. To do this, open the issue page, click "Edit
metadata" in the sidebar, and add a tag that says "needs_markup". Me and
hopefully a couple other people will check the issue list occasionally
and mark up and commit anything with that flag.
Important note: If you are assigned to an issue, but something happens
and you know you're unlikely to actually be able to cover it for any
reason, please drop the issue as soon as you find out. We want to avoid
a last minute rush.
There's a lot to go through and F28 Beta is coming out in a few weeks
(March 27 by current schedule). The main target is to have hopefully
everything written up by final release, which is currently scheduled for
May 1, but that's always subject to change. The sooner stuff is done the
Finally, if you know of any notable changes in F28 that don't have an
open issue but you feel should be covered by the Release Notes, go ahead
and open an issue. Note that we prefer to focus on new features; writing
about bugs that have been resolved or known issues would be nice but
it's a massive amount of work, so let's avoid that unless it's really huge.