Discussed in 2017-10-30 meeting.

Next step: Porting our docs

The next best step is to port some of our static wiki content over to a Fedora Docs-style publication. The blocker for this work is #123 (@bex is working on this, will be finished soon). Then, ticket #118 details the work needed to port over more of our own wiki documentation. An example of a specific page is #122.

Once #118 is closed, we will spend time documenting our process for migrating wiki pages to documentation and help other teams / sub-projects with this work. Until then, removing the meeting tag from this ticket and will follow up once we are farther along with our documentation.

Related: pagure.io/fedora-commops/onboarding-guide

Fedora 28 milestone deadline

This issue is tagged for completion during the Fedora 28 (F28) milestone. The F28 milestone ends on Tuesday, May 1, 2018. This issue will be bumped to the Fedora 29 release cycle.

Discussed in 2018-04-30 meeting.

Next steps

The next step is to file smaller sub-tickets to accomplish this larger goal of a general team onboarding guide / reference for other sub-projects and Fedora teams. In our meeting, we identified the immediate next step to review and research how other sub-projects bring in new contributors today, and look for common characteristics across existing content.

Content for different audiences

In the meeting, @dhanesh95 mentioned the idea of splitting content between types of teams, like outreach and development teams. We agreed that we can add a subheading or extra section with specific tips to the general document (e.g. Advice for programming language SIGs), and if we end up with more specific content than we expected, we can create new documents.¹

¹ Possibly a cool opportunity to try out modular docs with <include> blocks…

Background context

The deliverable is write effective guidelines on how to on-board someone to a Fedora sub-project or team. The guidelines offer suggested best practices and helpful steps for any sub-project to follow (e.g. using Pagure issue labels, mailing list introduction templates, etc.).

This is a different approach than we took before. A long time ago, we tried to create new onboarding guidelines for every major sub-project in Fedora ( #34 / #60 ). This was an ambitious goal and we were unable to complete it. This approach of a single, general document offers the best use of time for the largest impact on the community. By writing a general list of tips and best practices for sub-project onboarding, many teams can start from a general base and "shape" the guidelines to meet the specific needs of their teams.

Splitting up tasks

I am actioned to split this ticket into smaller sub-tickets. I will work on that this week.

sub-tickets

#168
#167
#166
#165

Maybe we need more sub-tickets

@bt0dotninja ¡Gracias Alberto! Thanks for taking the time to split this ticket up into smaller tasks. We can carry out further discussion in those tickets.

I did create a public pad[1] to work all the related tickets, some has good comments that works as starting point for a brainstorming :smiley:

[1] https://etherpad.gnome.org/p/CommOps-OnBoarding-Series

@bt0dotninja The best place to start is probably with research. We can open a call for contributions on #165. I may have time to work on it after I get through the FAW announcement and Flock recap CommBlog posts, but I don't have bandwidth for it yet.