Run a 2-3 "hackathon"-style event to improve Fedora quick docs, targeting Fedora support groups to help improve Fedora's documentation
There's several knowledgeable people in all of our support groups. They get a lot of feedback from users and they are usually the first ones to help someone find a fix. A great pool of knowledgeable writers for things like quickdocs could be from this pool of people who spend so much time already answering a "live support"-style version of the content already in quickdocs.
I was thinking of ways to mobilize this group of people to contribute to something like quickdocs, so it could be a unified place of reference for all of our support groups, even ones we don't have actual Fedora contributors in (kind of a cool way to insure giving up firmness in letting people self-organize things like this with our name).
I see this as a two or three day sprint to encourage new contributors and contributions to Fedora Quick Docs. We need to connect with the Fedora Docs team (e.g. @bex @zoglesby @jsmith @pbokoc @pmkovar et al) to create "easy-fix" style tasks and issues for things to work on, or make it as simple as possible about how someone could write and contribute a new quick doc for a topic we aren't covering.
We would ask contributors to help improve our quick docs or add missing topics for things they normally find themselves supporting.
Outreach to our support communities is essential. This is a unique group of people who not only have a lot of knowledge about Fedora, but also the questions people ask. Their perspective from the support end is valuable because they directly understand user needs or interests, and can help us make our documentation more relevant for more people.
The format of quick docs as topic-based documents makes this easier too.
I see badges playing an influential role here. I suggest creating multiple versions of the same badge for various support communities we want to target (e.g. Reddit, Discord, Telegram, FedoraForums, etc.). Then, someone who contributes could claim to "come" from one of these communities by linking their profile or showing some sort of verification of their membership, and we would award them the Quickdocs Hackathon badge for their support platform. This would be an extra motivational step to try and get people to jump on-board (e.g. a special badge for Telegram users only to get might be more unique and special to earn than a general badge – the idea of selective targeting).
I talked about this with @bex last week, and he mentioned that some of these items (not necessarily all) should be in place before running the event:
I think this is blocked by Antora and possibly the improved quickdocs navigation, but curious to know what others think about it.
Metadata Update from @jflory7: - Issue untagged with: help wanted - Issue tagged with: blocked
Any help needed with this?
Metadata Update from @jflory7: - Issue tagged with: team - docs
Metadata Update from @jflory7: - Issue untagged with: blocked - Issue priority set to: needs review (was: waiting on external) - Issue set to the milestone: Future releases (was: Fedora 29 (to Oct. 2018))
Discussed in 2018-10-10 meeting.
We learned the Join SIG was discussing similar types of things. We decided to start a new Discourse thread and share it with the Join SIG and Docs mailing lists, to invite people to participate on planning it out. If we have enough interested people to plan and lead this, we could try to start on it before 2019.
The Discourse thread is here:
Discussed in 2018-11-21 meeting.
In the meeting, we agreed to put this ticket on target for completion during the Fedora 30 release cycle. We didn't get much farther in the planning during yesterday's meeting, but we'll advance further on this over the next month or two. First steps will include some requirements gathering and figuring out the best way to approach this first.
We've had a lively discussion already over on Discourse around this topic.
Metadata Update from @jflory7: - Issue set to the milestone: Fedora 30 (to May 2019) (was: Future releases)
Metadata Update from @jflory7: - Issue priority set to: next meeting (was: needs review)
Discussed in 2018-11-28 meeting.
Next steps for this ticket are requirements / information gathering. Before running an event around contributing to Fedora Docs, we want to know: how hard is it exactly to contribute to Docs today? How we can we improve the user experience in tooling? If we can't solve it in tooling, what documentation is needed to better the contributor experience?
We decided on the following:
I'm going to draft up a few test scenarios and open new tickets for them by the next meeting. At the meeting, we will try to find volunteers to run through some of the test cases and gather feedback.
Once the new tickets are filed, I also want to start a conversation with the Design Team to collect feedback. These new tickets could be included in the article @bt0dotninja is putting together in #186.
So, one thing of note: even if this happens in March 2019 or later, it'd be ideal to largely fund it from the 2018 budget (because I don't think the Fedora logo refresh is going to be ready in time for the large order of swag and branded things in this FY).
Discussed in 2018-12-04 meeting and 2018-12-12 meeting.
The last two meetings covered ideas on improving the on-boarding experience for new docs writers and how to make the event more engaging / attractive for new contributors by game-ifying it.
And @mattdm, maybe we will inquire for budget after all. :smile: I hadn't thought about it, but it organically came up in today's meeting.
On May 16th, 2024, this repository was migrated from Pagure to GitLab, including all closed and open issues. This Pagure repository is being retired and set to read-only. We are committed to reviewing tickets on GitLab that are still open to determine whether or not they should be moved to the team's active planning repository.
If you want this issue to be followed up in 2024, please comment on the corresponding GitLab issue and let us know you are still interested in seeing it completed or implemented.
See the repository below for the imported issues:
https://gitlab.com/fedora/commops/archive/
This specific issue can be found below:
https://gitlab.com/fedora/commops/archive/-/issues/159
Metadata Update from @jflory7: - Issue close_status updated to: moved - Issue set to the milestone: None (was: Fedora 30 (to May 2019)) - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.