@giannelli.tech, I think it is great that you are raising an issue you are concerned about to the community, and I love how positive and collaborative the responses in this thread have been. That being said, I feel obligated to share my views on this topic because I know that were I not a woman, these views would be beyond the Overton Window. Even with this protection provided by my sex, I feel somewhat anxious about the type of responses I may get. But here goes.
Too often, we humans identify a problem by choosing a “Success Metric” and observing that the chosen metric has not been satisfied. Our solution to the problem thus discovered is to do what is necessary to satisfy our chosen metric. I’ll call this Reverse-Solutioning, because a solution is identified before a problem. Although the judgmental heuristics we use to select a Success Metric appear reasonable, this form of problem-solving often results in erroneous conclusions. “Salary should go up” seems like a reasonable Success Metric. However, if “salary should go up” is my Success Metric, then its lack of fulfillment must mean there is a problem, which is not necessarily the case. Naturally, there are many ways one can be successful in one’s career, and salary is only a part of it. “Mile time should go down” also seems like a reasonable Success Metric for a runner, but the conclusion that there must be a problem if my mile time is not going down is erroneous. If, after training diligently for years, I find that my mile time is no longer decreasing each week, I am not suddenly unsuccessful at running.
To return to the topic at hand, the chosen Success Metric and the problem it derives are implicitly stated, by means of the question: “Why aren’t there more women on the Core Team?”. From this question I surmise that a Success Metric has been identified, such as “an equal number of men and women on the RedwoodJS Core Team” (or perhaps just “more women on the RedwoodJS Core Team”). We observe that this metric is not satisfied, therefore a problem exists. I believe that this Success Metric is wrongly chosen and leads us to erroneous conclusions, such as “RedwoodJS will be more successful when the Core Team has more women”. What does success look like in this case? What is “more” women? What problem is being solved?
The best Success Metrics - those least likely to result in erroneous conclusions - are driven by the problem, which means a problem needs to be identified first. I believe (and here’s where we say goodbye to the Overton Window) that “not enough women in tech” or, in this case, “not enough women on the Core Team”, is not a problem. It may be a symptom of a problem but it on its own is not a problem. If a problem exists, it will not be solved by addressing the symptom, and often treating the symptom has its own unintended side effects. The unintended side effects of a Reverse-Solutioned problem deserves its own post, so I’ll leave it for now.
So what is the problem that RedwoodJS is trying to solve?
- Is the Core Team missing certain communication styles or methods of creative thinking common among women? How do you know?
- Is the Core Team’s effectiveness sub-optimal due to its small size? What does “optimal” look like?
- Are there not enough contributors to RedwoodJS in general? What is enough?
If we don’t begin with a problem, we will never know when we arrive at the solution.
I don’t know enough about the Core Team to comment on either of the first two potential problems, but these are good questions to ask yourselves. I do think I can delve into the third potential problem a bit.
There are too few contributors in general
As a still-growing initiative, I am sure Redwood could use more contributors in general - be it in code or design or copywriting or event-planning or project management. I would bet that acquiring commitment from individuals eager to contribute in these ways is challenging for any open source project, and Redwood is no exception.
This sounds like a problem, but not the root of the problem. We need to dig deeper. Why might there be too few contributors?
The culture of Redwood is demoralizing and unkind
Although my interactions with the Redwood community have been limited, I can say with a great degree of confidence that the problem does not seem to be a toxic, demoralizing, or unkind culture. Every person in this thread has exemplified how welcoming, how eager to help, and how kind this community is. In fact, when I began writing this post a helpful message was displayed reminding me to be kind. However, this is just my personal experience and I cannot speak for everyone. There can always be pockets of toxicity even in the best cultures.
If this is the problem, then rooting out any such toxicity should be a keystone value of the community. If people are being mean then it is your responsibility to speak up. Social pressure is a powerful tool, and it can be used for good.
A good Success Metric for this problem would be “When demoralizing or unkind behavior is displayed, community members call it out”. This can be refined further, for example calling someone names for calling someone names is not a good approach.
A possible solution to this problem could be including language like this in the community guidelines and advocating for it. Lead by example.
People are too intimidated to contribute
Many people feel intimated by the idea of contributing to open-source; they worry their ideas are dumb and the community will be mean; they worry they don’t have the skills needed to accomplish a task. Humanity’s best efforts involve a little risk and a lot of collaboration, and it is difficult to feel comfortable taking risks if you don’t know the people with whom you’re collaborating. At the beginning, contributing to an open-source initiative can feel like working on the Manhattan Project with an unknown number of people you’ve never met and about whom you know nothing. In that context, it might be difficult to feel comfortable suggesting an idea or believing your thoughts have value. It is hard to work on a group project with people you don’t know.
This sounds like a genuine problem, although not one unique to Redwood.
Because the level of intimidation a would-be contributor experiences is likely to decrease as they contribute, a good Success Metric for this problem might be “more new contributors”.
@alicelovescake has already explored several possible solutions to this problem, for example increasing Redwood’s presence at Bootcamps, giving tech-talks, and providing tutorials to the community. Targeting people who want to “build their first ____” (insert: to-do app, online store, blog, tic-tac-toe game) sounds especially valuable to me. Encouraging people to join the meetups is also an excellent way to give faces and personalities to the names we’ve seen on GitHub. Starting location-based threads in Discord for people to meet IRL is another way to connect and humanize each other.
Contributing to open source lacks sufficient reward
Contributing to open-source is unrewarding in the same way that volunteering is unrewarding. Your compensation is the thanks of the community, the heartwarming feeling of a job well done, the knowledge that you helped build something, and whatever you learned along the way. Many people never volunteer because they are too busy trading their time for money. Pitching contributing to RedwoodJS as an alternative to volunteering at a homeless shelter or visiting a children’s hospital or knitting scarves for orphans can be a hard sell for a lot of people. Of course, no open-source project would frame itself in that way, but time is finite, and this is the implicit decision being made by any person looking to do something with the precious time they have outside of work.
A good Success Metric for this problem could be “incorporating more ways for contributors to feel rewarded and appreciated”.
I believe the Redwood community already does a wonderful job at making people feel valued for even the tiniest contribution, so that should definitely keep happening. Other possible solutions are a “contributor of the month” award, or a spotlight post on a particular contributor in the community, or more badges you can add to your GitHub page (I heard someone mention this on the Contributors’ Meetup call, and I think it’s a great idea), or taking the time to endorse someone on LinkedIn for their efforts, or prizes (money, stickers, coupons for gum) for merging a certain number of PRs or answering a certain number of questions or just randomly on a lottery basis for being part of the community. The other thing people love about volunteer work is the sense of satisfaction we feel from altruistic deeds. Perhaps the Redwood community could collaborate on projects that scratch that altruism itch, like making over outdated websites for small businesses and NGOs.
Too few people know about RedwoodJS
Honestly, this could be a major factor. I found out about Redwood because I was trying to figure out how to build a full-stack website without needing to teach myself everything about building the backend, and I stumbled upon this framework. At the time I believe there was some disclaimer about it still being in development and that it could change in any number of ways at any time with no notice, so I decided not to risk it, but when I encountered it I thought it was just the coolest thing in web development I had seen. I still think that, and I know a lot of people would feel this way once they find out about it.
A good Success Metric for this problem might be “increasing visitors to the GitHub page” or “increasing downloads of RedwoodJS” or even “increasing contributors to RedwoodJS” (see: “recursion” 
).
A lot of the possible solutions that come to mind for this one are similar to the previous section. Sponsor hackathons, create a hackathon just for projects built with RedwoodJS, sponsor other cool open-source initiatives you like, produce tutorial content, ask Josh Comeau to spend some time looking into Redwood and blog about it, set up a table at university career fairs, attend UX and web development conferences, bring speakers to those same conferences. There are lots of ways to get involved in the broader community.
Here I have explored just four of the possible reasons more people are not contributing to RedwoodJS. I am sure there are others. What will make RedwoodJS successful is not Reverse-Solutioning a way to "more women” on the Core Team. For Redwood to be successful, it needs to continue fostering a kind and caring community whose goal is building exciting new technology for the web. Many people will be attracted to this goal, and some of those people will be women.
) but Redwood changed my mind. This has been an incredible community to be part of. I have met so many amazing people and have learned and grown so much - I even did a career pivot because of Redwood. I want the same for others.
).
…