ClassicPress Initiative and Project Plan

Objective

Set a clear plan for ClassicPress Initiative and the project once new directors take over.

Non-Profit

The ClassicPress Initiative (CPI) is a legal entity that must be managed by three directors as outlined in the bylaws. Three individuals volunteered to take on the responsibilities:

All three have been around ClassicPress for many years and want the project to succeed.

CPI has three main objectives:

  1. Fund ClassicPress project
  2. Manage ClassicPress infrastructure
  3. Manage business operations (forum, Slack, emails, bills, websites, etc.)

CPI will continue to be the owner of the project infrastructure. This ownership model eliminates any one individual from being in charge and prevents egos from getting in the way. This model also provides limited liability to everyone involved.

As a registered non-profit, CPI can fundraise money for the project’s expenses. Donations are tax-deductible in the US. The Open Source Guide recommends a non-profit if taking donations. No one should be personally responsible for the project’s expenses.

CPI’s initial goals once new directors take over:

  • Fundraising will be the top priority. Our initial fundraising goal will be $1200/year or $100/mo. That should cover all the expenses.
  • Cut expenses.
  • Simplify server infrastructure to cut expenses and make it easier to manage. William Patton will help with server management/operations.

Ensuring that those in the CP community with the skills and motivation to get work done have access to the facilities they need to do just that.

Directors that go MIA for more than 30 days without warning and attempts to contact them go answered will result in termination as a director of CPI. The remaining directors can appoint an interim director and begin searching for a new director.

For transparency, CPI will post monthly financials for the previous month.

ClassicPress Project

The project includes ClassicPress core, directory, documentation, etc.

CPI directors do not want the full responsibility of running the entire project. While the Directors will, as individuals, contribute to the development of the ClassicPress software, that is not the role of the ClassicPress Initiative, whose role is set out above. The development of the software is a community effort, which the CPI will support.

We are not in favor of having a rigid committee (or “council”) structure. ClassicPress did try the “committee” approach between 2018-2020. Unfortunately, it did not work out as expected and caused frequent disagreements between the members. Voting on issues became divisive and was one of the primary reasons for project stalling.

As members left or became less active with the pandemic in full swing, the committees were dissolved, and directors took on the responsibilities no one wanted to keep the project alive.

History should not repeat itself, and we must learn from it. Making decisions is worthless if those decisions cannot or are not acted upon. It is instead much more important that we focus on encouraging and facilitating people to actually contribute.

We do not want to be back at square one in a year with directors managing everything. The community must manage the project with the support of the CPI, though we envision that @MattyRob will continue to lead core development. Matt is happy to let someone with the necessary experience and willingness lead core development.

Access

Access to the infrastructure will be given to contributors doing the work on a “needs” basis. Anyone receiving access credentials must sign an NDA to ensure they do not share credentials with anyone and to protect user data for security and privacy compliance.

Thousands of users rely on ClassicPress to be a secure platform and ecosystem. We must ensure we do everything we can to maintain a high level of security.

ClassicPress used to have “team leads.” They were responsible for different projects, such as documentation, translations, core, etc. It worked well as long as they were active and doing their agreed work. This model may be worth revisiting and allow team leads to maintain access to their systems.

Petitions

It’s important for the community to share feedback and participate in the development of ClassicPress. We’ve had petitions since day one, and they’ve helped improve ClassicPress over the last four years. However, they didn’t live up to the expectations we all had.

We will be implementing the following changes to the Petitions:

  • Petitions will be renamed “Feature Requests” in the forum and everywhere else.

  • Voting will be disabled. If you want to show support for a request, leave a reply and explain why you think it’s a good request. If you think it’s not the right request for ClassicPress, voice your concerns.

  • All new feature requests will be moderated and must be approved by a moderator to be published in the forum.

  • All feature requests must follow the specified template. Feature requests that do not follow the template will be rejected, and the requester will be asked to re-submit using the template.

  • Feature requests that are far-fetched or have a solution, will be declined.

  • Once published, core contributors and community members can comment on it and decide if it’s feasible or not.

  • WordPress backports as feature requests will be declined. Backports must be submitted as an issue in the GitHub repo to engage the core team in a discussion.

This will require changes to the dashboard widget. The API data used by the dashboard widget will be frozen temporarily until the widget is updated in one of the upcoming releases.

Forum

  • Rules will be enforced.
  • Personal attacks and bullying will not be tolerated. Repeat offenders will be banned from the community forum.
  • Rudeness, especially directed at first-time posters seeking help, will not be tolerated. Users that may be angry because their website broke should not be attacked but allowed to cool off. Being condescending in your replies is rude and will not be tolerated. Many users are not developers and have little to no technical knowledge. They need guidance. First-posters should not be only-time posters because they get rude replies instead of help.
  • If referencing a conversation from Slack, it is advisable to copy/paste the conversation to the forum since Slack messages are deleted due to the plan’s limits.
9 Likes

Would there be a different category for CP software versus CP website versus CP documentation?

Does it make sense to split the requests and backports (which can be features and bug fixes), with one in the forum and the other in GitHub?
Shouldn’t everything to do with the software product be in one place?

Thank you for picking up the mantle. Quite a lot to discuss.

For the development, I am a strong proponent for moving petition and feature request discussions to github.

https://docs.github.com/en/discussions/collaborating-with-your-community-using-discussions/collaborating-with-maintainers-using-discussions

Most of the modern tools building the web have moved and are ok. For ages, WordPress devs kept asking for a change from SVN to Git but a middle ground has been found for this.

Personally, I seldom read forums unless someone links it or a bot does in slack or GitHub. We also do not have the man power to trac petitions and new stuff in forums, slack and Github. My humble appeal is that we use GitHub for development and features requests.

Forums can remain as a tool for support and feedback.

Moving to GH has Pros:

  • GitHub is evolving and new collaborative tools are made month in and out.
  • We can move stuff from issues to discussions boards if we open up discussion boards as in the link above and vice versa. This will yield faster PRs and triaging of issues.
  • Issues not be worked on can be closed and tagged won’t fix. Some one can quickly filter through PRs and Issues to see if their issue/petition is in won’t fix category.
  • Makes it easy to track things that need to be in future releases as well.
  • Reduces the overload of having a discussion of stuff in two different platforms +1 slack as well.
  • Github allows for interlinking of repo information and comments. The web interface and mobile app make things easier to work with.
  • We retain the conversation history in one platform for the future Devs. i.e What happens when we choose a new tool for forums like buddypress/ClassicPress from discourse.
  • Github Discussions has a polling system inbuilt should we ever need that.
  • Makes it s easier to convert and onboard testers, triage, teams and users.
  • most importantly, most the plugins and themes we use are now on GitHub. This can be a motivation for users to reach out to devs with one account to rule them all. (Excuse the pun)
    Most of the plugins have link backs to GH and not forums if we are to take careful note of this.

Cons:

  • Ordinary users just need a github account which is as equivalent to having a forums account. This is not a big ask considering the good stuff. Many non-tech writers are using git in their daily usage.

Platforms like Woocommerce and other big plugins have made it through having Github and slack. Forgive me if I overlook the work of relatives, Facebook groups and other fora.

I guess this might end up being a sub discussion but let’s hear other thoughts.

2 Likes

I don’t know if we need more categories or sub-categories, but I think this could be solved with tags. That’s a good way to use tags.

In the past, we’ve told petitioners to go to Github if they wanted to backport something. Our thinking here is that people who know what a backport/changeset is are developers. They should be the ones doing the backport PR and the core team can better help with it. It doesn’t need an official approval if they’re doing the backport. The core team can decide if the backport is good or not.

While the forum is left with requests that the community can discuss and show support for. A place non-technical users without GitHub can voice their feedback.

Do you think we should move everything over to GitHub as suggested by @omukiguy above?

This is my only concern, it requires two separate accounts. But, I’m not against it personally. Nothing is set in stone. Let’s see if more community members support this idea.

What would we do with the dashboard widget?

What shall we do with dashboard widget?

GitHub has a public API we can use to list the labeled issues Issues - GitHub Docs This shouldn’t be a huge challenge.

2 Likes