Contributing to ClassicPress

This has been on my mind for quite a while, but a couple of recent threads has crystallised my thoughts somewhat on contributing to ClassicPress.

The major issue I have trouble overcoming is methods of working:

  1. I work as part of a company where I have a defined role; consultant or manager:
    *. In the former role, a manager says these are your tasks, go do them.
    *. In the latter, a senior manager/director says these are the tasks for your team, make sure they get done.
  2. I work as the sole member of an open source project and decide what I need to do and what my priorities are.

I don’t really “get” the join a project and find something to do in order to contribute as there’s too much to understand.

It doesn’t align with either of my previous experiences (either professional or hobbyist). While I’m happy to help out and contribute, I don’t see the gaps and requirements that others seem to see and jump into.

I guess this is me saying, I can help, I just don’t see where or how?

I can do some PHP development (based on plugin writing experience), I can write documentation and blogs (I’ve done almost 2,400 blog posts and 8 books since 2011 when I started my blog), I have experience of testing and QA.

I realise that the ideal is probably someone who can see the gaps and requirements and just jump in, but, anyway, how can I be of use and contribute?

6 Likes

I understand the problem. I had the same feeling for quite a while. For me, the solution was to pick one area to really focus on… in my case, Classic Commerce. I started by doing a few simple PRs (all very menial, text replacement stuff - no coding!). But as I became more involved I could see more jobs that needed to be done - website, docs, etc.

It looks daunting when seen as a whole, but just pick one area and make it your main focus. Maybe you could choose one of the Research Plugins? This one needs some love: https://github.com/ClassicPress-research/cp-email-log

2 Likes

I also understand, maybe with our team updates we also start listing projects we are looking for help on and how to get started with them. That way we have a dedicated space where people can go to pick up things that they are interested in working on, or have experience in.

I think a running to do list, and more recurring team updates will help going forward. To get us started:

I would be happy to hand off the starting of team updates every 2 months or so, I often run out of time and then plan to do it the next month and then the process repeats… :slight_smile:

1 Like

One way is to fix existing bugs, reported in WP. There are lots of them, waiting years for someone with time and focus.
Another is to tackle one of the most voted on petitions. These are things a lot of people want changed. They need proposals on how to do them.

2 Likes

Just a quick example from WordPress that might be useful:

We should have a similar page with a list of tagged issues:
https://github.com/ClassicPress/ClassicPress/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

3 Likes

This already exists. A better place to look is the “help wanted” label across all of our repositories, because not all “help wanted” issues are “good first issues” (meaning easy): https://github.com/search?q=org%3AClassicPress+is%3Aissue+is%3Aopen+label%3A"help+wanted"

Similar links could be set up for the https://github.com/ClassicPress-plugins and https://github.com/ClassicPress-research areas.

But most importantly, we need people with both the skills and the motivation to get these things done. Finding the gaps and the requirements and just jumping in is also a key skill, as @azurecurve says. How can we make that a bit easier for potential contributors?

3 Likes

I’m going to talk to Wade about updates.

The problem with looking at bugs is severalfold:

  • I’ve only really experience of working with my own code or small plugins from others which I’ve forked and now have sole control over. I’ve no real experience or understanding of using GitHub on multi-user projects
  • It’s difficult to understand requirements sometimes for logged issues. The language used assumes a certain level of existing knowledge. Even items flagged as “Good First Issue” are often opaque to people new to the code (or at least to me).
  • I’ve never delved into core code before so it is somewhat of a black box.

It’s all very well saying “fix some existing bugs”, but that’s said by people with a good understanding of the ecosystem and tools.

That’s is a high bar which needs to be hurdled by someone new.

2 Likes