Let's integrate React with this app, for practice.

https://www.meteor.com/tutorials/react/creating-an-app

New user accounts should verify their email addresses before being able to proceed to the platform.

Logged-in users on /dashboard should be able to submit other entries to categories they do not have an active entry in.

Not sure if this is already in the works, but something I remember Exercism.io allows users to do is rate their mentor and provide feedback. I'm kind of assuming mentors actually want feedback on how they are doing as a mentor. 😅

Profile information includes:

• name (visible only to mods and the person they're matched with)
• email
• one-line intro
• Skill(s) they can help others
• Skill(s) they're looking to improve
• timezone

When a user clicks on the following link in their email, they should be redirected to /dashboard.

In the package.json the engines specifies node as 8.11.4, but this force us to run the application with only that specific version of node. This could be changed to

... rest_of_code
  "engines": {
    "node": ">= 8.11.4"  // => this is the minimum required node-version you need to have to run the application
  },
... rest_of_code

This can be enhanced by adding a .node-version or .nvmrc file - depends which node version manager we decide to go with (nvm vs nodenv) - to the root of the project, i.e:

# .node-version || .nvmrc
8.11.4

This will throw a warning if you try to run the application without having this version of node installed.

Sidenote: node is at 10.15.3 LTS at the moment, so we might want to upgrade.

There is a prompt for the one-liner to be atleast 8 to 140 characters long. But none for the details :)
Would you want to introduce a limit there as well, or make it optional?

Server logs show the following when I try to reset my password on https://cbconnect.herokuapp.com/forgot-password

Need to update the cards to include the skills filled out by the users.

Set up Travis so that it automatically deploys our staging branch to Heroku.
For reference: https://docs.travis-ci.com/user/deployment/heroku/

In our mockups, we've got step numbers to tell users that they are on step 1/3, 2/3, etc.

Not a super priority issue, but nice to have, so that users know that the application submission process is quick.

I think it might be worth looking into using dotenv to manage environment variables, like Sparkpost's API key. This seems to be the most compatible/reliable one I've seen for Meteor - https://atmospherejs.com/pauldowman/dotenv

The main problem statement here is simply a small inconvenience for now but I think could help future contributors in the long run. Currently, in order to get the authentication emails, we have to replace he password value in line 14 of dev-settings.json and ignore this when committing.

Ideally, each contributor can have their own set of environment keys that doesn't checked in with git. I think using environment variables to manage these for us should help users get up and running easier and allow for better productivity.

I believe it might also give us a simpler way of running local versions as you probably shouldn't need to append --settings dev-settings.json when starting up anymore.

Of course this is a tiny optimization for now, but can be helpful in the future. Posting this here for discussion as we're going to be aware of this when deploying to Heroku as well.

Currently we have 31 warnings on missing prop validations. To follow modern best practices when composing React components, we should include prop types in our components (both for documentation purposes and type checking; will help us improve our tests).

To see all components with missing prop types, run meteor npx lint in your terminal and it should return you a similar list of warnings:

The goal of this issue is to reduce the list down to 0.

For reference, see:
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/prop-types.md
https://reactjs.org/docs/typechecking-with-proptypes.html
https://www.npmjs.com/package/prop-types

The UI on the cards in the board on the home page should match that of the cards on /dashboard.

Before:

After:

• A user should be able to click to "expire" an entry by editing their unmatched entries from the dashboard
• A moderator should be able to click to "expire" an entry if they see that it is spam, etc.

If anyone has objections, let me know!

Chose the same license as the main CB project: GPLv3.

https://www.gnu.org/licenses/quick-guide-gplv3.en.html

Useful for testing the app on localhost:3000. @distalx mentioned he was working on this.

We accept pattern="[A-Za-z]{5,50}" for the name and pattern="[A-Za-z]{8,140}" for the one-line intro, but it's not immediately obvious to the user right now that the name can't include numbers, for example. Or that it has to be between 5 and 50 characters.

TODO:

• Return an error warning about the requirement for each field

Feature Story:
As a matched user, I should be able to connect with my matched partner intuitively.

--

The original idea stated that matches will be emailed by the platform so that their personal email addresses are anonymized. A matched user can then reply to the email and an email chain will be created:

platform emails both matches,
match 1 replies back on the thread ---> gets sent to the platform ---> gets sent to match 2,
and then vice versa. 

I think there's an in between layer here that handles the emails from the server side, but that seems very murky to me currently.

--

I want to propose that we explore alternative routes as multiway emails are really difficult to manage + outside variables that can potentially send emails from our platform to a user's spam folder, then missing connections.

I think it might be a more doable challenge to build out an in-platform messaging feature as we can control the environments more proactively, and also be able lean in more on Meteor's own reactive system (data on the wire philosophy).

We would still need to use emails as a form of notifications, but at least that way we've cut that down to a one way flow (our only responsibility is to notify users, we don't have to listen for incoming messages).

--
Relative issue for reference: #8

Add abilities to automatically deploy to Digital Ocean once PRs are merged into master branch. Should set up checks and balances to ensure that things aren't breaking when released into production, and if they do, have a way to rollback to a stable release.

- screenshot of gif created by @distalx

Each card should look something like this:

Or alternatively, each card would only contain the "more description" value the user filled in, but mousing over the card would show a popover containing the one-line intro and timezone:

Change the name of the route from /home to /dashboard. (This is the page that users see when they are logged in.)

On
,

we need to add three testimonials:

1. "I will say emphatically, your idea was a success!
   Gaurav was excellent. The lost concepts I had were clarified. I will spend the day practicing what he has taught me and move forward.
   I look forward to reciprocating one day."

• Albert Fougy, Developer

"I have chosen to be a part of CodeBuddies Connect because I believe everyone needs to share their knowledge with other people. In the wonderful CodeBuddies community, there are many students who want to acquire new Computer Science skills. Thanks to the Connect program, we have a chance to help them and learn more along the way. Also, we are doing the most important thing: "Free education"." - Zoran Pandovski

3. Find someone willing to give a third testimonial

On step 2/3, we've got some help text underneath the "more description" box:

We should adjust it depending on the category the user selected on Step 1/3.

For example:

• Coding/Accountability Partner
  e.g. I am working on ______ and hoping to accomplish my goal of ______. Looking for someone who can ______.

• Feedback/Career Advice
  e.g. I am working on ______ and wondering if ______. Looking for advice on ______.

• Mentor
  e.g. I am working on ______ and struggling with ______. Looking for someone willing to meet in a hangout/chat about/pair on ______ with me for _________ (30 minutes/an hour).

• Mentee (I would like to mentor or teach)
  e.g. I have experience with ______ and interesting in teaching/mentoring someone on ______. Can meet for 1 hour this week/Would prefer to chat over text only, not in a hangout or call.

• An Open Source Project to contribute to
  e.g. I have experience with ______ and am interested in working on a project with the following technologies: _________. I'm willing to contribute ______ (code/design/documentation/project management).

• Potential New Contributor(s) to my OSS project
  e.g. I started an open-sourced project called ____ and am looking for contributors who can help with ________ (code/design/documentation/project management). Technologies involved: ________________.

• Other (Not mentioned above)
  e.g. I am looking for ________.

Feature Story:
As a moderator, I should have the ability to add users as moderators so that we can have more help moderating the platform.

See:

Users should be able to edit their own entries, as well as make them inactive (see: #30).

We need to make it accept punctuation like , and ! as well. Otherwise the form won't let the user go through.

The validation is in the HTML, I believe.

When a user finished inputting their information and hits submit, the endpoint hangs up.

The meteor console reads:

I20190506-14:40:07.608(-6)? { Error: Invalid login: 535 5.7.8 Sorry.
I20190506-14:40:07.612(-6)?     at SMTPConnection._formatError (C:\Users\chris\AppData\Local\.meteor\packages\email\1.2.3\npm\node_modules\node4mailer\lib\smtp-connection\index.js:558:19)
I20190506-14:40:07.615(-6)?     at SMTPConnection._actionAUTHComplete (C:\Users\chris\AppData\Local\.meteor\packages\email\1.2.3\npm\node_modules\node4mailer\lib\smtp-connection\index.js:1254:34)
I20190506-14:40:07.616(-6)?     at SMTPConnection._responseActions.push.str (C:\Users\chris\AppData\Local\.meteor\packages\email\1.2.3\npm\node_modules\node4mailer\lib\smtp-connection\index.js:341:26)
I20190506-14:40:07.616(-6)?     at SMTPConnection._processResponse (C:\Users\chris\AppData\Local\.meteor\packages\email\1.2.3\npm\node_modules\node4mailer\lib\smtp-connection\index.js:707:20) I20190506-14:40:07.617(-6)?     at SMTPConnection._onData (C:\Users\chris\AppData\Local\.meteor\packages\email\1.2.3\npm\node_modules\node4mailer\lib\smtp-connection\index.js:510:14)
I20190506-14:40:07.617(-6)?     at TLSSocket._socket.on.chunk (C:\Users\chris\AppData\Local\.meteor\packages\email\1.2.3\npm\node_modules\node4mailer\lib\smtp-connection\index.js:658:51)
I20190506-14:40:07.618(-6)?     at emitOne (events.js:116:13)
I20190506-14:40:07.618(-6)?     at TLSSocket.emit (events.js:211:7)
I20190506-14:40:07.619(-6)?     at addChunk (_stream_readable.js:263:12)
I20190506-14:40:07.619(-6)?     at readableAddChunk (_stream_readable.js:250:11)
I20190506-14:40:07.620(-6)?     at TLSSocket.Readable.push (_stream_readable.js:208:10)
I20190506-14:40:07.620(-6)?     at TLSWrap.onread (net.js:597:20)
I20190506-14:40:07.621(-6)?   code: 'EAUTH',
I20190506-14:40:07.621(-6)?   response: '535 5.7.8 Sorry.',
I20190506-14:40:07.622(-6)?   responseCode: 535,
I20190506-14:40:07.622(-6)?   command: 'AUTH PLAIN' }

If the in-browser console is read, you can see some sockJs errors such as

The connection to ws://localhost:3000/sockjs/663/ushrz9bh/websocket was interrupted while the page was loading.

Users should be able to block another user they were matched with. If they block the user, they'll never be matched with that other user again, and won't see that user's entries.

Evaluate and implement a continuous integration service for open source projects (Travis-CI, CircleCi, or CodeShip). Main priority is to be able to run our testing frameworks on PRs and report back into GitHub so that we can automatically see if PRs are mergeable without failing specs.

--
Secondary goal would be to automatically deploy main branches (staging or master) to our Digital Ocean droplets as soon as conditions are good, but I think this part might need a broader discussion.

After applying, a user should:
[X] get an email asking them to verify their submission

[ ] After they click to verify the account, they should be redirected to their profile page (right now it looks like the profile page should be /home, but users are actually redirected to a link that looks like http://localhost:3000/enroll-account/G-qr9CR7NTLM4uhWemg-39oXMDnwIQ9OXPwCtMH--I after they click to verify in the email.)
[ ] Logged-in users should see a link to "Dashboard" on the navbar
[ ] On Dashboard page, users should see:

• an option to submit another card
• An anonymous board of already-submitted cards
• hearts on each card to click on, indicating they want to be matched with that card
• A list of previous matches
• An area where where the new pending match is displayed. Here, they can click to accept (start a conversation with) or reject the match.
• An option to expire a card they previously submitted
• An option to edit a card they previously submitted

Current issue is that our timezone can sometimes be too long to fit inside a MatchCard component.

Proposing to breakdown the timezone into two segments so that they can be rendered as:

One approach would be to splice the timezone value and splitting them in the MatchCard component.

For example, if timezone returns the value of

'(GMT-12:00) International Date Line West'

use JS to split at ) (or use regex to split the value from (...) and everything else) so that we can add a break in between in the MatchCard render function:

render () {
   ...
   <Card.Footer>
       <small className="text-muted">{timezone[0]}</small>
       <small className="text-muted">{timezone[1]}</small> 
   </Card.Footer>
}

where timezone is now an array of ['(GMT-12:00)', 'International Date Line West']

--

A second approach would be to refactor the entries file so that the timezones are already split accordingly:

The reason: we don't have any obvious corresponding categories that we can match people to (who submit to this category).

Adding e2e tests should help test out our React components as a whole; currently unit testing React is a bit weird as we're relying on DOM rendering; Writing some BDD tests on how our UI is suppose to function and work should help lower manual QA and solidify feature specs.

See: https://www.cypress.io/

See: https://www.youtube.com/watch?v=538Zu3Y0xTA

Not a priority; can do later.

Draft: https://docs.google.com/document/d/1PGiUmTHzon16y9LsWuUKBVgDRXB6Al1p3akyuCW4DOM/edit

https://docs.meteor.com/api/email.html
Make MAIL_URL undefined and it will log the email to the logs.
Else you get an error :(

Revamp current landing page to

For specs, the page is split into halves - the first six columns for a wide display are for the main content, and the second six columns are for the carousel displaying a series of MatchCards components. The carousel would have to be built. For an idea of how the carousel should work, see this comment.

Other details:

• The main primary colors use #277FE3 (primary buttons, h1 elements, a tags; not shown in this design sketch, but navigation links should also follow the same pattern: #277FE3 for link color and #386496 for hover color).
• The h2 tag and other body text color uses #386496.
• Lean in on React-Bootstrap components before making your own.

For additional reference, this is the Bootstrap theme were currently using - https://bootswatch.com/cosmo/

The two "skills" question in the original Google Form survey evoked some great responses which were more illuminating than the one-line intro, so am keen to add these two fields to the second step of the application form.

We can move the "More description" field to the first page for the form, since I often find myself forgetting the specific category I chose by the time I'm on the second page.

Brainstorming some questions folks might have... feel free to comment w/ more questions.

0/ What is CodeBuddies Connect?

1/ Why does it exist?

2/ How does it work?

3/ Can I request to be matched with someone in particular?

4/ How do I flag a user I do not want to connect with, after the match is made?

5/ How do I flag a user who violated the Code of Conduct?

6/ What are the expectations after I am matched with someone?

7/ Can I submit multiple entries at the same time?

Questions:

• Do we leave it all to the system to find a match based on two categories? (e.g. mentor -> mentee) and the description in the "learn more" section?
• Or do we also allow volunteer mods to click on two users, then hit submit, which fires off an introductory email between the two?
• Or do we rely on manual matching from the start?

The email will ask the user to log in to contact their match. Will file a separate issue about creating that inbox feature.

We need to design the UI for what the moderator will see when they log in to start manually matching cards.

Only moderators should be able to see click on two cards and click "match" to match the cards with each other.

The template:

Hey [NAME],

After sifting through all of the submissions, we narrowed down the perfect [OPPOSITE CATEGORY NAME] for you this week.

People who have connected through CodeBuddies have gone on to make projects together, host hangouts together, and keep each other accountable to their goals.

As a reminder, you said you were looking for:

[CATEGORY]
One-line intro of yourself: [ONE-LINE INTRO]
What skills can you help others with? [SKILLS HELP OTHERS]
What skills are you trying to improve? [SKILLS TO IMPROVE]
Timezone: [TIMEZONE]
General availability this week: [AVAILABILITY]

Your CodeBuddy is [NAME OF PARTNER].

[NAME OF PARTNER] is looking for [CATEGORY NAME]
One-line intro of [NAME OF PARTNER]: [PARTNER INTRO]
Skill(s) [NAME OF PARTNER] can help others with: [SKILLS HELP OTHERS]
Skill(s) [NAME OF PARTNER] is trying to improve: [SKILLS IMPROVE]
Timezone: [TIMEZONE]
General availability this week: [AVAILABILITY]