Our Roadmap
kognise opened this issue · 46 comments
Below I'll try to assemble a checklist of things we have to get done before shipping a semi-stable beta that's close to a finished product.
As I see it so far:
- Sort Out Additional Tech Stack Decisions
#24 #34 #145 #76 #32 - Determine Web Browser Support
#144 - Sort out Authentication
#40 #33 - Finalize an API
#17#46#257 #120 #253 - UI/UX mockups #114
- Add Initial Documentation to Wiki #12
- Build super basic MVP based on the MVP Project Board
This is vastly simplified, maybe we eventually want to move to a task management solution? Anyways, I'd love feedback on what this is missing. I tried to link up some issues/PRs but I'm probably missing a lot.
@kognise This looks awesome and gives us some direction over the coming days. I don't mind chiming in on API discussions, but I have been focusing on basic docs right now - I'm happy to be CC'd on that topic. I don't have any experience developing API's, though I am learning.
@kognise I think Chris is more working on the 3rd bullet, "Build a list of contributors and make the project more welcoming"
Love this checklist. I'm super keen to help, but minimum experience on working with OSS project. So I'm looking forward to see how people can contribute in this initial stage
@kognise I'll try to supplement what @chrismgonzalez is doing by summarizing who's contributing on the various issues and seeing if we can tap into the couple hundred volunteers sitting on the sidelines waiting for some direction.
Do we have some way of prioritizing the backlog? Project Board maybe?
@SeanFromIT I think we could consider using either GitHub Projects or Trello - @QuincyLarson what are your thoughts on this?
Really like if we can use Github Projects so that we can have one source to go. I found Trello and Github Projects not have much differences, unless you're using the Trello Powerup
I agree with @martindavid , it's better to make it centralized
@kognise I wonder if we could make this issue and the "Roadmap" info on the bottom of the Readme better gel together and/or cross-link
Can we include a focus on shipping before it's a viable product? The concept is to verify that the way we build this is shippable seven before we're build the first feature:
@kognise First of all, thank you for creating this comprehensive list of the work that needs to be done.
Rather than try and move to a tool like Jira, I propose we use GitHub's built-in project board to organize our work. It doesn't have as many features, but everyone here can use it without creating new accounts or learning new tools.
I've gone through and reviewed all the open pull requests and most of the open issues.
It's 2 am and I need to get some sleep. Once I wake up, here's what I plan to do:
Formally announce this project
I'll write an article introducing this project to people in the freeCodeCamp community, and explain our initial vision for what we want to build, and for whom.
Grant write permission to some contributors who have already proven themselves helpful.
Here are people I'm definitely doing this for based on their contributions so far:
- @bernhard-hofmann
- @kognise
- @dmmulroy
- @francocorreasosa
- @vaibhavsingh97
- @abbott
- @erictleung (based on his numerous contributions to freeCodeCamp over the past 4 years - not specifically to this project yet).
I would welcome other nominations. This is just a fast-pass. We can add more people later. I just want to make sure I am not the only person with permission and thus a bottleneck to progress.
Finalize our initial tools and feature set
People will continue to come forward for suggestions for tools and features. That's a good problem to have. But it will slow us down. If we can nail down a spec, we can work to quickly ship an MVP - possibly by next week.
Do we want to use Swagger for the MVP?
Do we want to use Next.js for the MVP?
Do we want to use ElasticSearch for the MVP?
Even if it's crude, this will be a big win for the community, and it will help us preserve momentum. I'm thinking we record a ~2 minute video demo of the API with a very minimal UI and we walk through all the user stories.
Again, momentum is key here
We have all the talent we could possibly want on this project. And we have tons of people who themselves lead chapters (some multiple chapters) who can give us user feedback.
The greatest risk to the project is that we get busy or distracted and this team wilts away to just a few people who end up taking much longer to build new releases.
As long as we all keep discussing ideas, opening pull requests, and getting user feedback, we can build a great free open source tool that will help thousands of organizers and millions of participants.
Random internet stranger passing by. I use Meetup and attend an open source event in town every month, and even occasionally present. I think we'd be tickled pink to be able to organize the event through open source software too. :)
I have a lot of experience with GitLab CI/CD and have used it to rapidly prototype web apps. It's got Kubernetes integration, works well with anything that's got a Dockerfile, and brings up a new environment to test each branch. They offer free CI/CD for public GitHub repos. If you have a Kubernetes cluster handy, it doesn't take much time to set it up to try it out. (They also offer some bonus starting credit for a GKE instance, but I haven't tried that before since I just run my own cluster)
My plate is pretty full, so I don't know how much I can help out directly, but at least I can throw in some ideas and experience for an interesting project.
Any possibility to have a kanban or any of the like so I can see where I can contribute?
@letorruella It looks like in all likelyhood we're going to use GitHub's built-in kanban board thingy, GitHub Projects.
@QuincyLarson we're having some backlog on the PRs. I've suggested @nik-john to ping someone else with write access via his PR #46, but I see now you said you'd grant write "when I wake up".
Both @nik-john (API / schema) and @chrismgonzalez (leading the Docs) have been committing and asked how to get write perms.
@allella I've granted several people including yourself permissions on this repository. You should now be able to go through and help clear the outstanding PRs.
Hi everyone, in order to provide some more clarity as to what I'm envisioning for Chapter, I've created this draft of how we would announce it to potential users.
These are just my opinion, based on my direct experience with dozens of freeCodeCamp chapters over the years. This may be less relevant to other organizations.
I wrote this after a long day, so if you notice any typos or fact errors, please let me know. Here we go...
Chapter - A Free Self-Hosted Tool for Managing Your Organization's Local Chapters
As of 2019, managing an organization with local chapters is still a pain.
freeCodeCamp has dozens of active chapters around the world. These chapters have regular events with large turnout. But they're organized using a mish-mash of Meetup.com groups, Facebook groups, and WeChat groups.
Meetup.com is expensive. With Facebook and WeChat, it's hard to reliably reach your own group members.
All three of these tools require you to share your community's data with third parties.
And none of these platforms offer a good way to get your member's email addresses so you can migrate to a new platform. Instead, Meetup, Facebook, and WeChat try and lock you into their platform.
These platforms do serve two major purposes, though:
Purpose #1: They can help you publicize your events and organically draw in participants from the platform at large.
This is thanks to these platforms' social network monopoly effects. In social, the winner takes all. And these platforms are the winners.
Purpose #2: They give you convenient tools for creating events, managing RSVPs, and sending updates to your participants.
Chapter will have these features. But instead of serving as a one-size-fits-all solution, Chapter will be designed specifically for multi-chapter organizations.
Chapter is your own meetup.com in a box
Chapter is a self-hosted chapter management tool. It is a "Meetup in a box" for your organization's chapters and events.
Here's how Chapter works.
Step 1: One-click install Chapter on a cloud server of your choice.
Chapter can live on a Linux server anywhere - Google, Amazon, Azure, other cloud providers, or even your own personal server room.
A cloud server capable of running Chapter should only cost your organization US $20 to $40 per month.
Then you can just paste the server's IP address into your browser's address bar.
You can set up Chapter through its in-browser admin panel. There's no need to dig around in a codebase or a command line interface.
You can run Chapter on a subdomain of your organization's website. For example, https://chapter.freecodecamp.org or https://events.freecodecamp.org.
Chapter has a well-documented API. So if you want, your team can integrate your chapters and events into other parts of your website or mobile app.
Step 2: Add your chapters
Chapter gives you the flexibility to structure your chapters however best suits your organization.
You can add country-level chapters, state/province-level chapters, city-level chapters, or even neighborhood-level chapters.
You can add as many chapters as you want to each region.
Each of your chapters can include photos and videos from past events, social media links, and other details to entice people to its events.
Each chapter can have sub-chapters. For example, your California chapter might have a Los Angeles sub-chapter. And Los Angeles might have a Hollywood sub-chapter. And Hollywood might have a West Hollywood sub-chapter.
This makes it easy for participants to understand the subchapters and where they fit into your larger organization. It also makes it easy to invite the right people to larger regional events.
Step 3: Add leaders
Your leaders can help customize your chapters and add details for local events.
Each chapter can have as many leaders as you want. Each leader can add their own title, bio, social media links, and contact information.
Step 4: Leaders can add local events
Each of your chapters has its own events calendar. You can set up an event in seconds. Just add a name, time, location, and any special instructions you have for participants.
You can have as many events as you want. You can even set up recurring events.
Participants can RSVP for these events. They can then one-click-add these events to their calendar tool of choice.
Step 5: Set up your email lists
As of 2019, email is still the most reliable way to reach most people.
When a participant registers for a chapter's events, they can get added to that chapter's email list. You can also automatically add them to other email lists, like your organization's master mailing list.
Chapter will send out emails to people when they register, when they RVSP for events. It will also remind them of upcoming events they've registered for.
You can grant leaders the ability to send emails to their chapter's participants as well.
You can configure all of this. And you have full access to the mailing lists and the full database.
Chapter gives you full control over your data and your destiny
Tools like Meetup.com, Facebook Groups, and WeChat Groups don't actually let you get your members' email addresses. They force you to communicate with your members through their own messaging tools.
At any point, those organizations can make decisions against your interest. They can send their own messages that contradict you. They can - and often do - get hacked. And you may not even realize any of this is happening.
And worse of all, when it comes time to move off of those platforms, all you can do is tell people "hey - go over here" and hope that they go.
In other words, you're building your castle on somebody else's land.
Contrast this with Chapter. With Chapter, you own everything. All your data stays in your database on your server. Your data doesn't go anywhere you don't tell it to go.
You can customize the way your instance of Chapter looks, feels, and functions.
Chapter has the most permissive open source license available. This means that if you want to, you can even dive into the codebase itself and change the very fundamentals of how your Chapter server works.
Frequently Asked Questions
How well does Chapter scale?
You can host thousands of chapters on a single server. You can have millions of people RSVP for events each month without needing to significantly increase your server size.
So Chapter is really free?
Yes. We are building it so our nonprofit can use it. Some other nonprofits are using it to. It's not limited to nonprofits, of course. Anyone can use it for free.
There is no paid tier. There are no advertisements. Your organization gets the same tool we're using.
Can freeCodeCamp provide a Service Level Agreement (SLA)?
At this time, we can't enter into any contracts around this. You can create issues and request features, and our project contributors will help as much as we can.
If your organization has developers, we would welcome their open source contributions to the project as well.
How does Chapter work on a technological level?
Chapter is built using popular and time-tested open source tools like Node.js, React, SQL, and Docker.
Our organization is new and doesn't have any chapters yet. Is this tool for us?
If you don't have chapters yet, we recommend starting with some of the social network event tools. This will also help people discover your event.
Chapter is designed more for organizations that already have existing participants in their events, and existing awareness of their communities.
Can I link my Chapter server with other organizations' servers to help people discover our events?
We are exploring ways that smaller organizations could band together to have shared event directories. This isn't part of Chapter's initial release.
How does Chapter help my events get discovered?
Chapter is optimized for search. Particularly Google search and Google location search.
This said, Chapter isn't magic. You will still need to publicize your events and raise awareness of your Chapter with your existing members.
Can I white-lable Chapter?
Yes. You can replace the Chapter logo - and logos in emails - with a logo for your own organization.
Can I charge event participants when they RSVP?
Currently Chapter has no payment functionality. We may add an option for this in future versions.
Aside from server costs, what other costs are associated with running a Chapter server?
You will need to add an email service to Chapter. Popular options include Amazon SES, SendGrid, and Mandrill. These have a small cost per email. Amazon SES, for example, costs $1 per every 10,000 emails sent.
How soon will Chapter be available for my organization to install?
We don't have a hard launch date, but we are working as fast as we can toward a stable release.
Good callouts here on what Chapter isn't (a discovery tool), as well as the graph-y nature of sub-chapters. Also makes it more obvious that if someone wants cross-chapter aggregation, the best place to do that would be an external service that scrapes multiple instances' APIs, rather than having something similar built in, at least for rev one.
FIXED
s/when the RSVP/when they RSVP
Or did I read it wrong?
@QuincyLarson That vision sounds flexible enough to fit a broader use case, such as my interest for supporting the tech meetups in my local/regional community.
"Collective" is the term proposed to describe a collection of chapters hosted on the same server instance.
It's probably smart to update the Terminology and/or the vision statement to use a similar vocabulary.
Chapter can live on a Linux server anywhere
If it's going to be a Docker container it could also run on Windows.
FIXED
Let me know if you're not aiming for a final draft and I'll avoid these little points:
s/The can then one-click-add/They can then one-click-add
The word "uses" in this line seems out of place:
You can customize the way your instance of Chapter looks, feels, and uses.
Might I suggest
You can customize the way your instance of Chapter looks, feels, and behaves.
@kognise #21 should kickstart when the backend is ready. The job should be done alongside the frontend. As for Localizing the frontend to other languages, that will come pretty later after all components are localized to a single json file for the default Locale, so for now. I will watch the issues as they are being addressed and PRs form others. But @QuincyLarson, which Methodology are we gonna use for the Project Management. Are we gonna work with sprints? How do PRs get reviewed. Are we creating tickets for tasks? Is the Backlog transparent based on the issues? Kindly drop your response. Cos if there are tasks on the backlog, anyone can pick them, this makes the tasks faster and trackable. I want to propose Jira for this even though it isn't open source. Any better alternative to Jira?
@komputarist @kognise I think there should be another issue related to the methodology which we are going to use! Is anyone interested in making a separate story for this?
@allella The issue with the word "collective" is that it has a specific meaning: "an organization or business that is owned and controlled by the people who work in it." It usually applies to separate organizations who work together.
Some organizations who use Chapter could be described as collectives, but freeCodeCamp and other 501(c)(3) nonprofits are owned by the public - not the people who work in it. many other organizations would not be.
Thus, the term "Organization" is more accurate than "collective." Even though "organization" is a mouthful, it is the most accurate term in this case.
The word "uses" in this line seems out of place:
You can customize the way your instance of Chapter looks, feels, and uses.
Might I suggest
You can customize the way your instance of Chapter looks, feels, and behaves.
"The way it uses" is something I've heard designers in San Francisco say. You're right - it's kind of jargon-y. I've reworked that sentence.
@QuincyLarson "Organization" works. We weren't hitched to "Collective". It came out of trying to eliminate the value "group" in the schema. We've renamed the core object to "chapter".
We'll update the Terminology to use Organization to represent a running instance with 1 or more chapters within.
Question. For design folks, what issues should they go to for contributing to the Chapter UI?
@cameronsr #5 is closed, but I think the people on that thread were the most design-oriented conversation I can recall. I'd suggest reading that thread and searching the issues for UX and design and see if you can connect with the people who have been driving those conversations.
We definitely need to get the UI stuff going. Will make a relevant issue and tags for it.
I'm assuming we're going to officially publish last nights video chat notes on Github. I think it would be easy and nicer looking to post the notes in .md format instead of a PDF so we can reference/link them in the Github (#) way.
Regardless of the format, once those are posted we should be able to refer and close at least #24 , and probably #32 to the notes.
I can convert the notes to .md format if we decide on where best to put them on Github.
I second turning notes into markdown. Placing the .md on the root alongside Contributing and Readme should be enough. It could serve as /get titled as a Bulletin-board of sorts. Going forward, we may just consider consolidating meeting notes and integrating them into current documentation after a set period of time to keep the root neat.
#116 I love TDD (Test Driven Development) process, it will help us to write future proof code and for that i am suggesting Uncle bob's clean architecture for api development. It is helpful when you want to write unit test.
@allella Yes - we could put the notes from our meeting in a documentation folder. Or we could just use a GitHub wiki. We've used them in the past with freeCodeCamp, and they are limited but will probably suffice for the short term. Would you be interested in creating the wiki and adding the notes from our meeting there?
Hi everyone, this is the main issue we have rallied around.
I've updated @kognise's original post to reflect the decisions we've made so far and the work we've done. I've also removed all the post-MVP steps so we can stay focused on our MVP.
I made some executive decisions to help move things forward. There are now 3 critical path issues:
- Initializing Sequelize: #120 (delegated to @Zeko369)
- UI Mockups: #114 (delegated to @vkWeb and @finisher1017)
- Documentation: #12 (I created our GitHub wiki to serve as the initial home for our documentation, but we need a volunteer to create these individual articles)
I have installed Chapter locally and am able to run it using Docker. Congratulations everyone on getting Next.js installed here.
Regarding the API, once we've merged #120 how much more work will we need to do before the database is in place and we can start writing the API logic?
Are there any other big steps that we should add beyond the ones listed at the top of this issue thread?
Are there any other big steps that we should add beyond the ones listed at the top of this issue thread?
The decision on what UI lib to use. Semantic UI?, Material UI?, ant design, React Bootstrap and others..
@ThomasRoest I'm not sure a consensus has been reached about a UI library, or no library.
#114 (part of the roadmap) holds some of the earlier conversation, along with #121 and #34.
Also, Quincy's vote was for using a UI framework to start and not custom-building from the start.
we can just grab a framework off the shelf and use it for our MVP, then write our own custom, more-optimized UI code later.
@ThomasRoest We've used Material-UI on past projects and found it's pretty flexible. Any tool we consider using should be at least as fast, flexible, and conventional-looking as Material-UI.
The October 20th, 2019 meeting notes are now published as a page in the Wiki.
It seems the vision statement above, has gotten hard to find, even for active members.
On Discord, it was suggested by @timmyichen to link to the Vision statement comment, or even create a separate Wiki page or VISION.md. Thoughts on which would be best practice?
Alright, unless there's suggestions otherwise I'm planning to make the vision statement above a Wiki page and then link to it from the README at the top near the similar, existing content.
The Vision comment, above, now exists as a Wiki Vision page.
The README will be updated to link to this vision page.
I'm closing this in favor of using our GitHub project board: https://github.com/freeCodeCamp/chapter/projects/1