Create contributors.json

[KJLarson]

Making sure I understand how to use Git/GitHub in a collaborative environment by submitting a pull request that adds an empty file (I've mostly just used GitHub for my own projects and practice repositories). That seems pretty safe. Am I doing this right?

Progress on #51

[logicalphase]

Looks good, Kari.

[KJLarson]

Thanks!

So, now do I keep doing it like this? Working on the add-contributors branch on my forked version of the repository and creating pull requests?

[rviscomi]

Yep, your workflow is perfect: fork this repository, work on individual features in separate branches, file a PR to merge each branch with the upstream master. 🙌

Only suggestion I can think of is to reference the issue you're addressing in the PR description. GitHub will add annotations linking them together to make it easier to find. For now just add Progress on #51. In the future if the issue should be closed after the PR is merged you can add Fixes #51 and GitHub will do it automatically.

Let's leave this PR open and have you push a couple more commits to your branch to build out the feature. We'll coordinate in #51.

---

One general tip since you're not used to working collaboratively. Remember to pull from the upstream master before you file the PR, to merge in any changes others may have added. In this case everything looks great.

Check your remotes by entering git remote -v and you'll probably only see your fork labelled "origin". You can add the upstream repository as another remote by entering git remote add upstream [email protected]:HTTPArchive/almanac.httparchive.org.git. Now, whenever you want to merge changes from this repo with your local fork, you can just enter git pull upstream master. And you can keep your origin up to date with git push.

[rviscomi]

See #51 for next steps

[KJLarson]

I think I understand how to do the contributors.html file, but the python files are tripping me up! I'm probably totally off with that stuff, but I tried to work it out. I would love feedback and/or some hints (maybe something for me to research that would help me figure it out?). Thanks!

[rviscomi]

Thanks @KJLarson this is looking great! Very close to the finish line, just left a few comments and then it should be ready to go.

[rviscomi]

@KJLarson let me know if you get stuck with any of this. I'm available to walk you through it over chat.

[KJLarson]

Is there a way to view all the suggested changes for a file together rather than broken up into all these separate bits? I'm having a hard time making sense of all this and figuring out how it goes together. I'm sure several nights of poor quality sleep doesn't help (:-/)
Thanks!

[rviscomi]

Try this view: https://github.com/HTTPArchive/almanac.httparchive.org/pull/57/files?utf8=%E2%9C%93&diff=split

[KJLarson]

Another question...do you have any suggestions on how specific to be with commit messages? It seems it wouldn't be too helpful (in most cases) to just say "update filename."

@rviscomi - I really appreciate your feedback, patience, and question answering!!! Thanks!

[rviscomi]

do you have any suggestions on how specific to be with commit messages? It seems it wouldn't be too helpful (in most cases) to just say "update filename."

Naming things is never easy 😁. For commits I like to have a short 1-liner describing what it is that I did. For more complex commits with many changes, I also include a list of each major change within the commit. For example:

add support for new widget

- optimizes widget performance on mobile
- removes redundant call to drawWidget in widget.js
- adds authentication to SuperWidget users

GitHub will name the commit based on the first line and add the rest of the commit message to the description. For small commits don't be afraid to be brief.

[KJLarson]

I think I'm stuck on main.py and contributors.py.

For contirbutors.py, I can't tell if it's done or if there are more changes needed.

For main.py, I can't tell if:

• the @app.route for contributors on line 28 is complete and I can delete the @app.route I added on line 53, OR
• if they need to be combined together, OR
• if the @app.route on line 31 isn't done, but the stuff I added isn't what it needs.

[rviscomi]

Just a few small changes left!

[rviscomi]

Once these changes are finished, the only thing left to do is to test out the page by visiting http://127.0.0.1:8080/2019/contributors with the development server running. You should see the info for the 3 contributors in the config file.

[KJLarson]

Well, shoot. I tested it and got this:
NameError: name 'contributor_util' is not defined

It looks like it's referring to line 33 in main.py.

Edit: I think I see the issue...when we imported it, we used "contributors_util", but when we returned it, we used "contributor_util". I'll change it!

[rviscomi]

Ok @KJLarson there comes a time in every open source contributor's life when they have to face the dreaded merge conflict. For you, today is that day! 😄

#60 was just merged, which affects main.py. You've also made changes to that file, the same lines in fact, so now git doesn't know how to properly merge them after doing a git pull git://github.com/HTTPArchive/almanac.httparchive.org.git master (or similar, depending on how you set up your remote repos locally).

After syncing to master you'll see this error message in the terminal:

Auto-merging src/main.py
CONFLICT (content): Merge conflict in src/main.py
Automatic merge failed; fix conflicts and then commit the result.

If you open up main.py you'll see this:

def contributors(year, lang):
<<<<<<< HEAD
    # TODO: Get contributor data and pass into the template.
    return render_template('%s/%s/contributors.html' % (lang, year), contributors={}, supported_languages=supported_languages)
=======
    contributors=contributors_util.get_contributors()
    return render_template('%s/%s/contributors.html' % (lang, year), contributors=contributors)
>>>>>>> 4ec6c11f9ef25c73c71cff37f1d5e80a663cecd4

There are two sections to this, the part between HEAD and === (the latest contents of the file) and the part between === and >>> (your changes to the old file). To resolve the conflict, we need to merge the two sections while preserving old and new changes. Here's how I would merge them:

def contributors(year, lang):
    contributors=contributors_util.get_contributors()
    return render_template('%s/%s/contributors.html' % (lang, year), contributors=contributors, supported_languages=supported_languages)

(Note that none of the <<< === >>> scaffolding should exist in the code after merging)

After saving that change, if you run git status you'll see this:

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   src/main.py

So run git add src/main.py and git commit which will generate a merge commit. You don't need to modify the commit message, it already contains info about what you're merging. After pushing, the conflict should be resolved and the PR will be ready to merge with the master branch.

[rviscomi]

Whoops. This commit totally rolls back the progress on this issue. Can you add these changes back in and only delete the duplicate contributors function definition above?

[KJLarson]

🤦‍♀️ Oh my, I think I'm getting confused. It's tricky looking at the changes and suggestions with the green and the red!
Is this what we want?:

def contributors(year, lang):
    contributors=contributors_util.get_contributors()
    return render_template('%s/%s/contributors.html' % (lang, year), contributors=contributors, supported_languages=supported_languages)

[rviscomi]

Yes, that's it! Also make sure to keep the "import contributors" bit above.

[KJLarson]

Where is the "import contributors" bit?

Thanks for your patience!

[rviscomi]

This part is required because the contributors method calls contributors_util.get_contributors().

[rviscomi]

LGTM!