Discussion: CodeBuddies v3 Future Projects

[angelocordon]

The original CB platform was built to serve a mission --

Let people organize remote-friendly meetups that are accessible to other self-learners regardless of their location.

Over the years, it's served that mission quite well and has evolved to so much more with projects revolving around building out our community, from slackbots to discussion forums. At this step, one could ask, what's next? Where do we go from here and where can we go?

It's not necessarily that we as a community lack ideas, in fact, we have 32 open issues marked with a [type] feature tag and about 8 open issues marked as a [type] bug. There's a lot of space for the platform to grow to, and a lot of opportunities we can consider.

However, in order to figure out what's next, perhaps we can consider some current pain points.

From a technical standpoint:

• Good chunks of our codebase is unwieldily, tightly coupled and we lack some important tests that could solve/prevent some of our current bugs (Issue: intermittent problems signing in to codebuddies.org #1109, for example).
• This also makes it challenging, and perhaps even un-motivating, to extend the current codebase. Creating, extending or maintaining components of the platform is a challenge because the pieces someone needs to work on a feature are coupled in various places of the codebase. (Not specifically but somewhat related: fix project structure #1071 (comment))

From an opportunity standpoint, we have a few great ideas that can really flourish if decoupled from our current processes:

• Having a way to build other kinds of integrations into the community without having to couple it with the current codebase would make maintaining these kinds of integrations easier and allow for these projects to be more language-agnostic. (for example, building slackbots to connect both our Slack community with our online platform instead of building the bot inside the platform codebase).
• This ties in with the technical pain points, we're missing opportunities to teach others (primarily new developers) best practices when collaborating on projects. I think we lack proper on-boarding documentation and processes to get someone up and running and be able to contribute properly. More experienced developers seem to become "better" contributors to the repo, but I wonder if our current processes leave out less-experienced developers.

I've purposely left out solutions to these pain points as that's something that we should all come together. Feel free to leave more pain points that you've felt as a contributor or member of this community and we can edit this list.

What are everybody's thoughts?

[lpatmo]

Thanks @angelocordon! Curious if @RuubixO, @tgmiller5, @Dan-Y-Ko, and other newer contributors (or who've expressed interest in contributing) have thoughts about pain points they've encountered.

[d3vild06]

Here's my thoughts:

• As noted and highlighted by Angelo and Linda. The project is serving its purpose and mission. Would I consider it a "platform"? No. I think this is limited by the current tech stack.
• If we are simply saying since the project is serving its mission, we don't need to consider improving it or keep it modern, then we've already failed this community.
• I strongly believe this community serves two distinct audiences. Those who are users of the site and those who are contributors to the code base and project. We are mainly addressing the latter here and the focus is on improving the development workflow, maintainability and sustainability of the code base/platform.
• One of the main issues we have today is the lack of contributors and we're left with one or two meteor "experts" that end up doing most of the contributions and making most of the decisions.
• There's a huge opportunity to migrate to a tech stack that allows us to create a true platform and build features much quicker.

I also want to note that the lack of feedback is also possibly an indication that we have less interest in contributing due to the existing tech stack.

I truly believe CB can be amazing and create a community and platform that provides a space for folks to learn how to code together. We must continue to evolve and grow together.

[lpatmo]

There's a huge opportunity to migrate to a tech stack that allows us to create a true platform and build features much quicker.

What features do you envision in v3 that would make it a true platform, @d3vild06?

Side note: my original dream was multiple spontaneous coding meetups happening at the same time, and in the course of building this I've realized that it's less of a features problem and more of a finding-meetup-organizers problem.

If we are simply saying since the project is serving its mission, we don't need to consider improving it or keep it modern, then we've already failed this community.

IMO it's less of a "let's not improve the codebase" issue and more of a maintainer burnout issue. Unless CB becomes a funded, full-time project for some of us, I think it'll be difficult for anyone to find the time to lead on it. But if I am wrong about maintainer burnout, and folks would like to lead on a new tech stack/turning the website into a more active platform, then that would be exciting.

One of the main issues we have today is the lack of contributors and we're left with one or two meteor "experts" that end up doing most of the contributions and making most of the decisions.
That is true; a lot of the more major features come from more senior developers who are able to pick up Meteor quickly.

[distalx]

Things evolve.

This discussion was started with a suggestion of porting to a new tech stack (MERN). & now we are discussing version 3.

When the project was started things were not as tightly coupled with Slack as it has become today. And most of the feature requests that are being filed includes slack.

Slack has its limitations, And people have created a bot to address those limitations - even In our community people have created a few projects like greet-bot, buddybot, CB-jarvis. And still time to time we find new use-case that we hope slack could handle it out of the box (Recent example someone suggested: the ban people for limited period of time ).

So If we are in the process of envisioning a version 3, we need to make a list of those type of use-cases, compile user-stories and move forward with new attempt.

"Exercism did that" -- they created a new platform from scratch.

[d3vild06]

To help with the discussion (and @distalx's point around outlining specific use-cases and features) here are some ideas and vision for CB v3:

Product/Feature Focused

• Create better engagement through different forms of communication and incentives (i.e. push notifications to your mobile device, desktop notifications, robust member profiles, gamification)
• Make the match-making code buddy service a first-class citizen (not standalone site)
• Create a more content rich platform & site where videos and articles are posted and available right on the site for FREE
• Create a community-driven global knowledge base
• Establish partnerships with teachers and mentors in the industry to give talks or teaching lessons
• Establish partnerships with relevant sponsors (to help with cost)
• Live hackathons
• Create an incentive program for meetup organizers and mentors

Tech/Developer Focused

• Make it a true platform where we can even expose a public API some day
• Focus on improving the developer experience and community (for contributors)
• 3rd party service integrations to help provide solutions to our list of features (think online code editors, video and music services)
• Testing is part of our code reviews and features deliverables
• Tech stack is modern and allows for easier development of new features (tons of available resources and huge community)
• Front-end and backend are loosely coupled
• Easily deployable to any hosting platform
• Documentation is a first-class citizen

I spoke with Linda and she recognized funding this project will be critical. She has some ideas around running a kickstarter to help get this kicked off.

[lpatmo]

My questions around running a Kickstarter are:
1/ Should we run a Kickstarter, or run it on Open Collective for easier management (and to dodge the taxes question, since Open Collective will be fiscally sponsoring the project as a 501c3)?
2/ What rate would be fair to pay the core contributors?
3/ Say we raise $3K, or $10K on Kickstarter. How will that get budgeted? Which contributors should get paid? Should it be paid-by-feature or pay-hourly-rate-up-to-a-certain-number-of-hours? What would be the expectations for the contributors who do get paid? Will paying some contributors and not others lead to resentment?
4/ How much of the $10K should be stored away for taxes if it is on Kickstarter?

[angelocordon]

Really appreciate the great dialogue so far 🙌🏽🙌🏽

Before we get too deep, it might be a good idea to figure out our evolved mission now that the community has grown, so that we have something these visions can anchor to.

In the beginning, it seemed like it was all about being able to remote meetups but basing on our current Slack channel, it seems like the core mission of the community now is to be able to provide a safe space and tools for developers of all levels to learn from one another. Anybody agree with this? I’m not in the forums as much so I’d love some perspective there as well.

If we agree that this can be our core mission, then I think figuring out how all the pieces in place can come together would be clearer.

[angelocordon]

Re: funding, I agree - I think trying to make Open Collective work might be better for us, at least this way we can concentrate on the things that matter and less on accounting/taxes. Eventually, if we become much bigger, it might be worth the effort of figuring that out more but until then, let’s try our best to keep that side simple.

I’d be curious to see how other OSS splits their funding; VueJS uses their funds from sponsors to pay for contributors also.

I wonder if we should think about a standard and transparent pay structure so that it can be more helpful to more developers.

In any case, I’m not opposed to figuring out a way for the community to get funding from sponsors.

[lpatmo]

In the beginning, it seemed like it was all about being able to remote meetups but basing on our current Slack channel, it seems like the core mission of the community now is to be able to provide a safe space and tools for developers of all levels to learn from one another.

Thoughts on the mission: https://medium.com/codebuddies/codebuddies-in-2018-a-project-status-letter-to-the-community-7f8c2c34e950

The primary mission: Connect people who have the potential to help each other become better at software development, regardless of where they live.

Secondary missions:
1/ Support and feature the personal projects created by members in the community.
2/ Support members’ career goals in tech.
3/ Be a space for constant individual growth and experimentation.

Figuring out a way for the community to get funding from sponsors.
Would anyone be interested in helping with this?

I agree we can follow the examples of other Open Collective projects like VueJS and Babel, etc. which have paid their core contributors. Another example is Free Code Camp -- which is different in that it is a 501c3 non-profit, but gets its funding entirely from small donations, IIRC.

[cbelsole]

My thoughts on funding:

One big way I could see CB improving is how we market ourselves. I didn't even know that I could sponsor CB on the Open Source Collective. I have rectified that.

• The splash screen on every hangout could say something like, "This hangout is provided by the good people at Codebuddies. Please sponsoring us on the Open Source Collective in order to keep us running."
• Push the donate link up to the top so that people actually see it without having to scroll all the way to the bottom of the page.

Changes like this will go a long way to getting funding since CB has a great product in its members and safe spaces to learn people will want to see that stick around.

My thoughts on the product:

I value that CB has stayed in its lane. It's not trying to be SO. It's not trying to be Free Code Camp. I imagine the V3 of CB to have more project managment tools not to duplicate Trello or Github in that regard, but I am imagining a way of orgainizing around a common project and templatizing and standardizing the creation of projects people want to work on. CB handel's meetups and discussions very well. This functionality can be leveraged by adding the ability to tie them to a well laid out project board that has everything up front that you need to see what the project is all about and how to contribute.

My thoughts on the tech side:

I agree with all points above. Getting off Meteor and using frameworks like React/Redux will go a long way to onboarding people. The only thing I'll add in that same vein is the backend should probably be in JS too. Other langages like Ruby, Python, and Go are great for spinning up backends quickly and in some cases preformant, but just like Meteor it has the gatekeeping problem whereas with JS you can expect that most if not all web developers will have some understanding of the language.

[angelocordon]

Re:

Getting off Meteor and using frameworks like React/Redux will go a long way to onboarding people. The only thing I'll add in that same vein is the backend should probably be in JS too. Other langages like Ruby, Python, and Go are great for spinning up backends quickly and in some cases preformant, but just like Meteor it has the gatekeeping problem whereas with JS you can expect that most if not all web developers will have some understanding of the language.

While I'm not opposed to this, I was also thinking that we can try to make opportunities for other contributors are really great at other languages as well -- not just JavaScript. I.e., if the backend was in Ruby, Python or Go, then we'd open up other opportunities for other "kinds" of developers to contribute to.

Of course, the complex tradeoff here would be we'd need some contributors to be able to lead that side of the platform in that language -- not sure if it's currently worth the tradeoff, but just wanted to throw it out there.

[angelocordon]

Some more :rubber_duck: thoughts based on the convo above:

We could essentially break down v3 platform/community goals to be something like:

The primary mission: Connect people who have the potential to help each other become better at software development, regardless of where they live.

and our community values should be:

1/ Support and feature the personal projects created by members in the community.
2/ Support members’ career goals in tech.
3/ Be a space for constant individual growth and experimentation.

Based on these, we can see which aspects of everyone's suggestions would help move the needle forward in terms of the community mission and values.

I'd like to highlight some of @cbelsole's suggestions:

• project management tools - a way to organize or standardize common projects and templates
• leverage how we already handle meetups and discussions and improve them; tie functionality to a well laid out project board so that a contributor can see wha the project is all about and how they can contribute
• highlight a way for members to sponsor hangouts and the organization through open source collective (alternatively or additionally, have a way to sponsor to organizers as well)

I'd also like to highlight some of @d3vild06's suggestions as well:

• Make it a true platform where we can even expose a public API some day
• Focus on improving the developer experience and community (for contributors)
• Testing is part of our code reviews and features deliverables
• Tech stack is modern and allows for easier development of new features (also opportunities for members to learn in relation to their career growth)
• Documentation is a first-class citizen
• Create an incentive program for meetup organizers and mentors
• Establish partnerships with relevant sponsors (to help with cost)
• Establish partnerships with teachers and mentors in the industry to give talks or teaching lessons

--
Overall, I think all are great suggestions, there are just some of the ones I think that we can draw a circle around based on the missions we want to achieve for v3 -- or at least v3.1

[wuworkshop]

@lpatmo will have to fill in the actual numbers of the CB Survey results from 2017. I just wanted to bring up the survey results so the feedback from users is actually factored in for v3.

https://medium.com/codebuddies/codebuddies-community-survey-results-really-insightful-commentary-from-yall-8dcb36965d71

In particular, I'm more concerned about the less experienced developers since they appear to be the majority based on the "How long have you been coding?" survey question.

For the "Do you have any suggestions/feedback for how we could improve our community?" question, here's some responses that caught my eye:

1. We need to find ways of engaging our users more. Also, we need to improve the experience for new users.

2. It is a little difficult to figure out how to get started.

3. I wasn’t sure how to start, there wasn’t a clear welcome message.

4. Maybe make it a little easier to get started with hangouts, in slack, etc. But I have seen great progress over the last year (2 years?!)

5. Redesigning the hangouts page on CodeBuddies.org it is alot to take in and can be very confusing to someone who is just coming along.

6. The Slack is really big as an entrypoint. I haven’t really been sure how to get involved.

7. Less channels (reduce bloat). Plan for physical meetups (study in person). Like Harry Percival, think about doing more AMA’s with tech authors/gurus to attract more participation (e.g. Dave Beazley, Cal Newton, Katrina Owens, etc.)

8. Hangouts could be made easier and all…it is a bit complicated at the moment to get in.

9. Regular hangouts by study group organizers. Try to let ppl not in US to take part in hangouts. Send survey out to find out what members want to learn and if anyone can volunteer to teach it.

10. More hangout, more pairing between people, dashboard with projects that we could work on.

11. Website aesthetics and design could maybe use some work.

[angelocordon]

Thanks @wuwuworkshop - those are excellent insights

[wuworkshop]

It occurred to me that the survey question was phrased "how we could improve our community".

Now that ~2 years have passed and some changes were made to the site, Slack, etc., perhaps a new user survey should be sent out to ask "how could we improve the CodeBuddies site/app?". 🤔

Also, since people clearly want MOAR hangouts, I'd like to know what is preventing users from starting their own hangouts. I feel like it's probably a number of reasons.

1. Less experienced people don't feel like they "know enough" to lead/organize a hangout.

2. Shyness.

3. The CB site is too overwhelming/confusing to newcomers (based on survey results).

4. Fear that no one will show up. 😞

And probably some other reasons I'm missing. Like perhaps not being comfortable speaking English? And, of course, there's always the time zone issue with having a global community. 🗺

[lpatmo]

Now that ~2 years have past and some changes were made to the site, Slack, etc., perhaps a new user survey should be sent out to ask "how could we improve the CodeBuddies site/app?". 🤔

++

This would help inform V3. Is putting together a draft of a new survey something you might be interested in, @wuworkshop?

IMO, creating hangouts at the moment is very much like creating remote meetup.com events -- very formal, since a user would have to fill in several details. I'm imagining a version where it'll be common to see several remote meeting rooms open all at once... kind of like Twitch streaming, in a way, but collaborative learning instead of one-way streaming.

[wuworkshop]

I feel like this can't be stressed enough - "Simplicity Wins over Abundance of Choice".

https://www.nngroup.com/articles/simplicity-vs-choice/

[d3vild06]

@lpatmo I love that idea of a "twitch" like streaming UI where folks can peruse for an interesting topic to join.

I know we're starting to get into implementation details but I love the ideas that are already flowing!

Do we want to decide where we want create and manage the project? We can always use Github's own project boards and manage the whole thing right here.

Thoughts?

[lpatmo]

I have no objection to using Github's own project boards!

[billglover]

I’ve been quiet here as I’m struggling to separate what I want from CodeBuddies from what would benefit the community as a whole. We probably should run a another survey. Was the previous one a Google forms survey? Are the questions available?

I strongly agree with @wuworkshop that simplicity, and clarity of purpose is incredibly important. Clarity needs to come long before we consider interface design and screen layout. What is it that CodeBuddies offers? How do we make that as accessible, engaging, and useful to all involved?

Anecdotally popular aspects appear to be:

• Water Cooler
• Advice/Support
• Connections
• Hangouts

Each one of these areas could be broken down into an infinite list of features, but I’m in favour of making the core functionality as obvious and accessible as possible.

It feels as if Slack is the place people spend the most time. It also appears to be the way a number of people join CodeBuddies. Is this something we want to embrace in the way we offer core functionality? If so, this would be a compelling reason to re-think how core functionality is built.

[lpatmo]

Thanks @billglover for your thoughts! The questions/results from the December 2017 survey are here: https://medium.com/codebuddies/codebuddies-community-survey-results-really-insightful-commentary-from-yall-8dcb36965d71

Core mission: Connect people who have the potential to help each other become better at software development, regardless of where they live.

Although many people have connected and helped each other on CB's Slack, I think V3 should endeavor to make the website itself an alternate popular gathering place, rather than rely on Slack integrations, for a couple of reasons:

• Slack will seem more and more intimidating for newcomers the larger the numbers count grows
• Over a certain amount of activity (say, a couple hundred active people, if we grow), Slack will be plain hard to keep up with

I have a few pet desires for V3 (a different UI to encourage more spontaneous live meetups, a learning resources mind map and learnings section/chatroom for each resource link, probably MERN), but it would be really interesting to see everyone else's top desires for product features laid out.

I'll try to draft up some sort of survey this week, and will share the draft for feedback.

[wuworkshop]

After reading some more links like these:

1. https://jdittrich.github.io/userNeedResearchBook/

2. https://www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users/

I'm starting to wonder if onsite user research should be done instead of an online survey. Or perhaps some of the money in Open Collective could be offered on https://opensourcedesign.net/jobs/ to do usability testing, user research, etc. 🤔

A book that might be worth checking out is "Customers Included":
https://customersincluded.com/index.html

[lpatmo]

I'll try to draft up some sort of survey this week, and will share the draft for feedback.

I created a draft of questions here: https://docs.google.com/document/d/1W4THgyKx9juLZNevHtnqkYN3rwDM95nxp8RqgMdBUi0/edit

Feel free to add to it/add comments.

I'm starting to wonder if onsite user research should be done instead of an online survey. Or perhaps some of the money in Open Collective could be offered on https://opensourcedesign.net/jobs/ to do usability testing, user research, etc. 🤔

We could definitely do both! (A community survey + user research.) Curious if anyone would be interested in coming up with a plan for usability testing/user research.

[angelocordon]

I think a lot of these questions are a bit too poignant and can result in some biased results. I'd propose we mix some of them with more open ended questions and less choice-based questions to allow our members be able to articulate more what's important to them. I've drafted a good few ones below the original questions.

I pulled some from: https://hackernoon.com/20-user-experience-survey-questions-and-templates-for-inspiration-27d7ba4f94c7

and for further reading:
https://medium.com/envoy-design/how-to-ask-good-questions-and-level-up-your-user-research-skills-19fd28b275a4
https://www.getcloudapp.com/blog/ask-unbiased-questions

[lpatmo]

Really love what you added here:

Currently thinking that we could have a few short multiple-choice questions to get an idea of the demographics (especially using Bill's suggestion):

Then, free-form those 12 user-interview questions.

Like last time, I can put up two Amazon.com lottery gift cards to incentivize participation.

[tgmiller5]

@angelocordon To add, I would agree to just include a couple of free text fields because when sending out a survey, most people may want to fill out the survey real quick instead of just typing so much based on their time and also if they are using mobile.

[angelocordon]

All good points 🚀

[wuworkshop]

Just wanted to add another link with some useful tips on creating a qualitative survey:

https://www.nngroup.com/articles/qualitative-surveys/

[RuubixO]

I'm coming to this very late, but the most powerful commodity of CodeBuddies is its ability to "glue" together the right people organically.

A lot of what I think about personally about what can be improved, and that could summarize a lot of what I've read here, is the ability to make and maintain connections easily, and to make our technology easy for others to contribute.

Slack:
I really don't like that we have serious fiscal limits on how much chat history we can afford to save. Those conversations teach me more than a lot of books--I'm not always in a place to copy and paste things until I can get around to digesting everything I learned through an interaction on the platform. We can't afford to expand this feature, and I doubt slack would give us a practical way of extending that as a free feature on our own.

Technical:
We could free ourselves from a lot of the language constraints by transforming the platform into a more modular structure--credit to those of you who have already mentioned the lack of loose coupling in the code base.

This would probably require us to have good api's and standards around them, which will require us to make a lot of new good documentation. This would also have the advantage of creating standards for tools before we accept them, so they could be their own projects without threatening the necessary functionality in the master branch.

I think moving towards a more independent set of tools that are completely open source will provide us with the flexibility to evolve with the group's identity. This will require a huge amount of work now, but it would be a valuable technical investment that will pay off further down the line.