Chapter Documentation

[chrismgonzalez]

Below is a basic documentation outline. Please feel free to add your feedback.

Getting Started as an Organizer

• Installing Chapter
• Create an organizer account
• How Chapter works

Using Chapter

• Creating and managing events
• Chapter and member communications
• Chapter settings
• Manage Members
• Group and event photos
• Member guide
• Sharing events

Account & Notifications

• Accessing an account
• Resetting your password
• Organizer subscriptions
• Notification settings

Technical Issues

• What browsers does Chapter support?
• Why am I not receiving emails?
• Why can't I upload a photo?

Policies and Community Guidelines

• Community guidelines
  • Privacy policy
  • Report a member
  • Report a group

Backend/Architecture

• API docs

[chrismgonzalez]

Eventbrite API docs
Meetup API docs

[bernhard-hofmann]

I'd suggest allowing authentication via Google, Facebook, Twitter, etc.

An important aspect of this from a user's perspective is to allow a single user account to be associated with multiple social/oauth accounts. (Both my Google and my Twitter accounts are still just me.)

[chrismgonzalez]

I'd suggest allowing authentication via Google, Facebook, Twitter, etc.

An important aspect of this from a user's perspective is to allow a single user account to be associated with multiple social/oauth accounts. (Both my Google and my Twitter accounts are still just me.)

How about this:

• Account & Notifications
  • Accessing an account
    • Social logins/SSO - Github, Facebook, Twitter, Gmail, etc

[chrismgonzalez]

Made edits to the above DOCS outline

[namvnngu]

In “Using Chapter”, in my humble opinion, we can create a small code competition in small groups/events to encourage users to not only study and increase their interactivity. Through the competition, they can achieve point/award to level up their position in groups, but we need to maintain their equality. Again, competition is just a small feature/playground for everybody to learn each other, but not a main point in Chapter.

[chrismgonzalez]

Proposed PR template that closely mirrors the main curricula:

• You have read the contribution guidelines
• Your pull request uses a descriptive title (not a vague title like update.md)
• Your pull request targets the master branch of chapter
• Closes #XXXXX

Proposed issue template that closely mirrors the main curricula:

• Is your feature request related to a problem? Please describe.
  A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

  • Describe the solution you'd like
    A clear and concise description of what you want to happen.

  • Describe alternatives you've considered
    A clear and concise description of any alternative solutions or features you've considered.

  • Additional context
    Add any other context or screenshots about the feature request here.

[allella]

@chrismgonzalez have you any suggestions for format of issue titles? It seems someone started out with a pattern on the features and we've gone all over the place since then.

[allella]

@chrismgonzalez I've not worked on a project with enough issues for it to matter, but I could imagine people posting Tasks, Research, Question, Ideas that may fall outside of the coding or implementation side. So, do we want those "other" things in the issue queue?

[allella]

I'm involved in local projects and not in tune with Free Code Camp's system and systems. Is there anybody here besides @QuincyLarson who's coming over from FCC's Github and has suggestions for what might work so we're not re-inventing everything on every aspect of managing the project?

[allella]

Looks like FCC uses tags more than title patterns so maybe that's the way to go.

[chrismgonzalez]

@allella I would like to propose that we maintain parity with the main FCC repo in terms of tag patterns. The consistency would be very helpful and unifying.

[allella]

Yeah, looking at the other FCC repos shows there's a lot to be borrowed. Though, some of it may be overkill until the project get's large.

[chrismgonzalez]

Agreed, let’s keep it down to just what we need for now.

[mojo706]

Hi for the contributors guide, I really always find this helpful as a link Working With Forks could this be added to the Contribution Guidelines? If it helps I can summarise it.

[allella]

@chrismgonzalez and others, Quincy gave a handful of folks write permission to Github and there are a handful of Discord moderators.

I think it would be handy to list these folks somewhere we can link to in one place. Thoughts on adding to the README, or perhaps better to add a Quick Link on the readme and link to a new page/issue.

Github Write Permissions
@bernhard-hofmann
@kognise
@dmmulroy
@francocorreasosa
@vaibhavsingh97
@abbott
@erictleung

Discord Moderators
These are Discord usernames and not necessarily Github usernames.
@ pixely#7774
@ sarvottam#4454
@ dharavihol#8588
@ QuincyLarson#8146
@ vkWeb#0291
@allella

[allella]

For instance, is MODERATORS.md a convention. Or, is there already an easy way to see this in Github and Discord?

Best I can find is people in Discord have a green username and the Insights page shows people who have committed, but not necessarily have write or more than basic access.
https://github.com/freeCodeCamp/chapter/graphs/contributors

[mojo706]

On discord you can add roles as a separate group such as mods. Then they will have a section on the right sidebar

[allella]

On discord you can add roles as a separate group such as mods. Then they will have a section on the right sidebar

So, that's a Discord setting someone would need to change and then everybody would see that in the sidebar? Or, is it a per-person setting?

[mojo706]

The owner of the channel is the one who would do that. It's really easy, on the settings.

[allella]

The owner of the channel is the one who would do that. It's really easy, on the settings.

I'll have to ask Quincy to do it. You have a screenshot or link that I can share with him? He's a busy dude, and I can't see the admin settings to map it out.

[mojo706]

So you click the dropdown next to the Channel Name, then you click on Server Settings

Then click on roles and create the roles.

Then there is a plus button that helps you create new roles 😌

[chrismgonzalez]

@allella I don’t mind having write perms if you guys are ok with it. I may have gone to bed before all of you decided that. If not, that’s fine, too.

We could add a table in the contributing guide and readme listing moderators/POCs. If there is someone that has a specific specialty, perhaps it would be wise to list them as a POC for a specific topic (front end, back end, Docs, etc.)

[allella]

@chrismgonzalez yes, Quincy thought it would be a good idea if I surveyed the issue queues to see who's helping a lot and identify topical POCs. He did a bit of by granting write via pull requests, so there will likely be some overlap. Still, I think it's good to associate folks with what they are focused on so we have some "quick people" and "quick links" to lower friction.

I also asked him to give you write permissions since you're heading up the docs.

[chrismgonzalez]

Sounds good to me! I don't plan on approving PR's unless they deal with docs. Additionally, It would be good to get more than just 1 set of eyes on everything before it gets merged in.

[chrismgonzalez]

Hi for the contributors guide, I really always find this helpful as a link Working With Forks could this be added to the Contribution Guidelines? If it helps I can summarise it.

@mojo706 Would you mind submitting a PR draft of what you propose in the quote above? Please reference this issue (but don't mark it for closing). I find myself referencing this information on a regular basis, it would be nice to have it included in the repo. This repo is changing rapidly so we need to make sure local forks are kept up to date as best as we can.

[allella]

I trust Chris on this as he's got a vision for the docs. I'm most comfortable organizing and reducing friction on the conversations by connecting people to people, and people to issues/PRs.

Still this triggered the question of if Quincy plans to brand this under FCC using subdomains for everything, which seems like it would get confusing, or eventually having a branded web domain for the broader Chapter brand.

[chrismgonzalez]

Yes, we'll need to wait and see how the branding plays out -- which is totally good. As I look on the Gatsby site showcase, it looks like FCC knowledge base that is linked to from the curriculum is a Gatsby site. This furthermore solidifies my initial thoughts of deploying the docs site (when we get to that point) as a Gatsby site.

[vkWeb]

My later vision is to create a docs site that is similar to the Gatsby docs
Looks like we have a structure in place. I'm going to pin this issue just so it doesn't get buried as more issues get submitted.

Yes, we can think of Gatsby. We'll confirm this at a later point.

@chrismgonzalez Instead of pinning, please label it as api doc or something similar. We can always sort issues by labels. We should only pin issues that need to be exposed to all users. It is helpful in cases when a bug is observed in production, to clarify confusions or to ask for help from contributors. :)

[vkWeb]

@chrismgonzalez It feels like you are very excited about the docs thing. Then you should lead our efforts for documentation ;)

Right @allella? 😄

[chrismgonzalez]

@vkWeb I understand your concern and I would like to go with your label system in the future. Could we keep it pinned for now since it is the central hope for all documentation as of this point in time?

I don't mind leading doc efforts. I feel like that is my strength until I understand the tech stack better and can contributing to the code.

Feel free to message me in Discord if you want to talk about it further.

[andyst81]

I'm really interested in helping out on this project, but feel that there are a lot of more capable programmers here already, so would be happy to contribute to the docs. I'm quite familiar with Gatsby too and enjoy working with it, so would be happy to do that, if that's the direction here.

[vkWeb]

@chrismgonzalez You raise a valid point. Let's keep it pinned for now. Sure, I'll DM you regarding the docs planning & set up when time comes :)

@andyst81 Welcome! No, it isn't like that 😅. We all are learning. Many are beginners including me. Feel free to contribute to docs section if you are happy with it. Every issue/PR helps us :)

[chrismgonzalez]

@andyst81 Welcome. You're help will be needed. I can't do all of it myself. Your contributions are more than welcome, even if you think they are small!

[gideonpraise]

A quick question please, (forgive me if this the wrong place to ask)...

Is there room for someone that is not a user to opt-in as a sponsor for an event?

[allella]

@gideonpraise thanks for your suggestion. There are two issues open, #83 and #84, to share suggestions in the format of a "user story". I'm not sure the suggestion will be necessary for the initial MVP build, but you're welcome to post on #84 so we have it in a memorable place in the issues.

[gideonpraise]

@allella Okay thanks. I will do just that

[QuincyLarson]

@chrismgonzalez Thank you for putting together this excellent list of starting documents.

I just created a GitHub Wiki for us to start with (we can later migrate these articles elsewhere, but this is a convenient place to begin).

I'm looking for a volunteer who can create each of these articles and a few paragraphs for each addressing its topic.

[vkWeb]

@chrismgonzalez I have updated the issue and added "help wanted" label to allow contributors to work on this. The documentation will be under your supervision.

Right now we can only work on API documentation as we are still implementing features for MVP. Once we have all the features down we can start writing documentation for accounts, members, organizers, etc.

[allella]

@chrismgonzalez I wanted to ask if you'd still have time and interest to stub out the docs in the Wiki, as Quincy requested in #47. Or, at least help us pull together a group and give the task some direction.

(I created our GitHub wiki to serve as the initial home for our documentation, but we need a volunteer to create these individual articles) - Quincy

You did a nice job moving things forward on the initial repo docs and that's sort of what we need on this stubbing phase. We obviously don't have an app to document, but Quincy suggested stubbing out the structure as another way to make everyone think about how users will interact with the app.

I'm better at things once there's more definition and feel I can help review new docs and put meat on the bones. However, I'm less enthusiastic about my ability to quickly create a docs skeleton without spending way too much time spinning wheels in the abstract.

For instance, I'm not even sure what best practices I'd follow. Organize docs by role? By section of the site? By user stories? etc.

Hoping you can help move this along and/or pull in more folks. For instance, we had a handful of offers to help with docs from #11, including @lcarbonaro @chipironcin @xarielx
and some others we can ping in Discord.

[chrismgonzalez]

@allella I will take a look. I'm on break from work all this week so I will have some time to sit down and work on some stuff. Thanks for keeping everything lined up around here!

[QuincyLarson]

@chrismgonzalez I've broken this issue out into separate issues and put them in our documentation column on our project board: https://github.com/freeCodeCamp/chapter/projects/1

Also note that our API documentation is created programmatically. @Zeko369 proposed us using a procedurally generated GitHub page that gets updated when people merge new code.

[chrismgonzalez]

That’s great! Will check it out this evening after the kiddo is in bed. Thanks for your help on this, sorry I’ve been absent for a bit.

[QuincyLarson]

@chrismgonzalez No worries. It's the holidays so I'm glad you're spending time with your kids. We are working to break all of this down to smaller bits so each contributor can grab more bite-sized chunks of work, and PRs can be more atomic :)