Do we know each other?

Or do we have a member list anywhere?

I think it would be interesting to learn

  • who would like to contribute to doc (and therefor may be considered a member),
  • what is her/his domain of expertise, and
  • what she/he intends /wishes to contribute, either quite specific, (e.g. guide about …) or more general (e.g. Workstation doc)
  • a link to her / his page at https://fedoraproject.org/wiki/User:<FAS_NAME>.

Just in case such a list doesn’t exist, wouldn’t it be useful to start a list on a Wiki page, so everybody could add her/himself to that list?

For me it would be

  • pboy
  • Fedora Server, system administration, information architect, web UX, University scientist by profession (major: Sociology, minor: applied mathematics/computer science)
  • Server documentation, improvement of System Administration Guide, in general Fedora documentation improvement
  • User:Pboy - Fedora Project Wiki
4 Likes

Count me in for this. It is a good idea.

It’s a starting point for my intro here.

hankuoffroad intro

1 Like

I will contribute.

  • py0xc3
  • docs: when I identify Docs issues/needs in ask.fedora threads (e.g., this), I will handle it; Later, I would like to also start to complement the warnings we have already in docs (such as “make backup before doing this”, “all contained data will be lost after doing this”) by security warnings (such as “this virtual network will by default enable arp/ip takeover if untrusted/captured machines are within, you can mitigate by doing this”) and maybe add related pages (some sort of red docs :). Security cannot be measured and many people don’t know about security issues they create when setting something up (most issues in the industry are related to the relevant security knowledge being existent, but not at the person that implements the solution). So, as people define their google queries for a solution to set up a virtual network among VMs (which is a need they can identify themselves), we can be at the point where they end up and make them aware of the issues they did not look for due to the absence of relevant knowledge :slight_smile: However, the second part is my long term goal and has to be discussed first; for now, I will focus on getting into the docs and learn how to do things there and also, support other open issues if they are related to my expertise. So: Workstation, Server, QuickDocs.
  • expertise: obviously, information security including some red-teaming experience, crypto (which does NOT refer to cryptocurrencies :- ) ; QEMU/KVM/libvirt; networks; after nearly two decades some experience in issue handling. My university background is both information security and international relations (in short, security in general :- )

Hi! I haven’t been around much lately, but I was in the past and would like to be more involved someday. I always have had a soft spot for Fedora Docs and it is one of the project areas that brings me the most joy to work on. The challenging balance for me is getting time to work on Fedora Docs outside of my day job, which at the moment, does not have much to do with Linux or systems administration.

I have historical knowledge on how and why the Fedora Docs are the way they are today. I was a participant at the March 2018 Docs hackfest in Bolzano, Italy, where we first made the steps to migrate off Docbook and to the Antora system we have today. I have a lot of knowledge about how the publishing magic happens with Fedora Docs today, although I suspect some of this knowledge is becoming deprecated in light of recent efforts to unify efforts around Fedora Docs.

A passion project I would like to one day revisit is something I proposed with CommOps three years ago. The project idea was to run a Quick Docs community hackfest with our user support communities, like Reddit, Telegram, Discord, etc. Many of these user support communities share advice and best practices on using Fedora Linux. There is a lot of great knowledge shared across these groups. Quick Docs could be a powerful way to bring these user support communities together, co-create common information, and help us deliver consistent documentation and support across the several decentralized communities Fedora operates in. The original idea is below:

https://pagure.io/fedora-commops/issue/159

But this is obviously a very big task, and probably not a good fit until there is a better foundation for Fedora Docs and the team around it. But something I wanted to mention as part of my introduction.

Not sure if I can fit the meetings into my schedule, but I am lurking on the Discourse tag and keeping an eye on discussions here. Hope to see y’all around, and do my best to keep up with the changes. :grinning:

1 Like

I like the idea, but I think we should do it as a docs page, not a wiki page.

My main concern in either case is that sort of information tends to become stale over time, but that’s a future problem not a now problem. :slight_smile:

1 Like

A doc page would be better, indeed, but the PR workflow makes it a bit more tedious to “just” enter the information. A Wiki page is more “quick but dirty” . And as with our other docs, we need to review / update it once a year or so.

Maybe we should create a dedicated page in the team pages and a brief template here and everybody can either create a PR or can add it as a message to the thread, and we find someone with commit permission to copy it over.

The template could be something like

<fas_name>::
* _Domain of expertise_
+ 
<brief (2-3 lines) descriptive text of ones domain of expertise>

* _Possible contributions_
+
<brief (2-3 lines) descriptive text about (the range of) possible contributions>

* _Fedora wiki homepage_
+
https://fedoraproject.org/wiki/User:<fas_name>
1 Like

If you are coordinating in these forums, I suggest write your information here and link to it as your “featured topic” (you can set it at Fedora Discussion).

If one is on multiple teams then can create a central topic that links to relevant project-related info templates about team members.

For your consideration. :slight_smile:

The feature is really nice. On the other hand, it adds another element to the unstructured and somewhat chaotic looking Fedora “information system”. With Fedora people we have “profiles” where Fedora specific info, e.g. badges, are programmatically supported. And then we have profiles in Hyperkitty, pagure, probably also gitlab, and other places. And now one more?

Scattering everything somewhere is an efficient way to hide information efficiently while making it inconsistent.

1 Like

I created a proposal at Fedora Documentation Team - HackMD

Please feel free to modify and improve the wording