As promised this morning I'm delivering a proposal to the current and previous maintainers of the Joind.in team to build a team to take over operation of the hosted Joind.in service as well as how the project leadership should be structured with an emphasis of cross training and mentoring the next generation of maintainers. I'm honored not only by the many people who joined a random Discord server to discuss the topic, but those of you who signed on to be named as part of the team that want to take on this task. I'm filled with a huge sense of optimism and I'm eager to jump in and get to work on Joind.in.

Here is the proposal in it's entirety below or view/download a PDF

Joind.in Project Management Proposal

My name is Joe Ferguson and I, along with the undersigned individuals would like to formally
propose building a team of volunteers to take over management, hosting, and operation of the
Joind.in service. I feel strongly that Joind.in was critical in my career as a technical speaker and
would hate for the service to not be accessible to future conference speakers. Operating an
open source project is a mountain of work often leading contributors and maintainers to burnout.
This proposal is specific in regards to how the project leadership should be structured with an
emphasis of cross training and mentoring the next generation of maintainers. No one person
should bear the burden of an entire project. Work should be delegated to eager individuals
interested in having a meaningful impact in not only an open source project, but the community
of contributors, speakers, and event hosts.

Most open source projects fail over time due to loss of interest and “real life” happening to
maintainers. If we take the approach of always being on the lookout for the next maintainer and
ensure we’re mentoring those individuals, we can offset some of the normal attrition over time.
Open source projects with corporate backing often last longer and are over all better projects
due to funding and support of a company. While at this time there is no parent company
involved in this proposal, it may be in the best interests of the project to establish itself as a
formal nonprofit company to better leverage funding from potential grants and incentivising
corporate donations via tax benefits in the United States. We would also want to find a
knowledgeable person around tax laws and how we could expand our nonprofit status to
international donors.

Goals

● Continue the hosted Joind.in service
● Continue development of the open source project
● Maintain a positive OSS culture and foster mentoring and learning from the lowest level
to the primary maintainer
● Empower and embrace our diverse community to teach and learn from each other

Project Structure

The project should be led by a volunteer leadership committee of at least three individuals:
1.“Primary Responsible Party” who would be in operational control of the project and
manage services and logistics of operating the project.
2.“Product Responsible Party” who would control and lead product focus of the project to
establish direction forward and guide implementation of user experience with heavy
focus on accessibility.
3.“Development Responsible Party” who would be responsible and lead the
development of the product based on input from the “Product Responsible Party” and
“Primary Responsible Party” and any subcommittees or work groups that may evolve out
of necessity.
4.“Security Responsible Party” who would be responsible and lead the security aspects
of the product based on input from the “Primary Responsible Party” and the
“Development Responsible Party” and guide the team towards building a secure
platform.

From these minimum three individuals can come any number of committees or work groups as
needed to share workload. Term limits for these roles will be limited to two years in order to
foster continuity and reduce the likelihood of burnout.

Short Term Plans (Now -- March 2019)

● Ensure access requirements are updated and secure
● Inventory infrastructure and versions
● Patch any known vulnerabilities or discoveries
● Start regularly scheduled cadence meeting of project managers to discuss and
communicate

Near Term Plans (Now -- July 2019)

● Review and prioritize Issue backlog (“Product Responsible Party”)
● Evaluate logistics of formalizing Project as an organization (“Primary Responsible Party”)
● Triage high priority issues (“Development Responsible Party”)
● Leverage past contributors to return to the project and pitch in

Longer Term Strategy (Later 2019/ 2020)

● Finish/consolidate versions/rewrites to a single platform, update build tooling and
processes
● Maintain a culture of mentoring not only new developers to OSS but also product
focused individuals as well as maintainers so that when a maintainer steps down the
organization easily shuffles around people to roles they are already familiar with.

I would love to schedule a time to talk through any questions or concerns you may have.
Thanks for your time, and thank you so much for all of your efforts to make Joind.in what it is
today.

Proposal Prepared by: Joe Ferguson
Proposal Team & Contributors: Paul McNeely, Andreas Heigl, Ian Littman, Mike Willbanks, Eric
Poe, Michael Cullum, Adam Englander, David Stockton, Scott Dutton, Jos Elstgeest

Many people have pointed out that this is just the beginning and there is so much more work to be done and I couldn't agree more. Assuming the Joind.in team accepts our proposal We'll need some information sharing sessions to get a state of the project, hosted service, and anything else. Here are a few next steps we are thinking about and planning for: (Note: not an exhaustive list and subject to change)

Info Exchange from maintainers to team

• Combell Account Credentials
• Domain Registrar Credentials (Andreas H. has access)
• Social Media Account Credentials
• Add to Github organization as owners
• Any other 3rd Party services? Mailchimp, etc?
• How is outgoing domain email handled?
• What system users exist and which can be cleaned up?
• Determine a go forward documentation platform (Github Wiki Probably?)

Product Tasks

• Review open issues across legacy, web2, and api repositories
  • Possibly close all over 2 months old?
• Review open pull requests across legacy, web2, and api repositories.
  • Possibly close all over 2 months old?
• Review and document the day to day tasks around site maintenance such as approving events, explaining why events went unapproved, etc
• Document Code style guide
• Document Testing guide
• Document Contribution guide
• Document PR review process guide

Hosted Site Stabilization

• Debian 7.8
• PHP 5.6.4
• Apache/2.2.22 (Debian)
• MySQL 5.5.49-0+deb7u1-log (Debian)
• Jenkins to Travis-CI? Conversion
• Path to GDPR Compliance

Initial Tasks

• Assess server layout and backup everything
• Is there any server configuration automation?
• What does the road to PHP7 look like?