How should we treat "spoilers"?

[kellhus]

Should we refrain from posting our solutions until a specific deadline? (This might not be feasible -- there can be issues with conflicting commits if everyone tries to submit things on the same day and has no idea what others have written in the meantime.)

Or should we let people be responsible for not looking at the solutions until they are ready? (And update the repository continually without a specific deadline in mind. This better approximates the typical forum or reddit-type-website experience.)

@AddemF @Thimoteus @pqnelson , what do you think? I myself prefer the latter option.

The Academic Integrity subsection of the README.md needs to reflect the decision.

[AddemF]

Yeah, I'm in favor of the latter. If you don't fully know the solution yet and want just a little push but not the full answer, you can communicate in the IRC or on Reddit, or whatever. Only start posting your answer or reading other answers when you feel you have it figured out.

This is just my conception of how our organization is evolving here, but it seems like this GitHub project is more of a polished object, or like a "finished project" (that isn't quite finished yet). It would make sense to me if we used Reddit as the kind of interactive, messy conversation where we post our attempts at solutions and have each other give feedback and so on. Then when we feel good about finalizing what we've done, we publish it here.

[pqnelson]

I actually do not know...because, ostensibly, I'd like to keep my solutions separate from someone else's. Not because I'm antisocial, but I don't want to get confused...And I'd like feedback on what I did well, or badly, or confusingly, or elegantly or...etc.

What is the current designation for placing solutions? Does everyone put it in a separate file? Or keep it locally? Or place it in the notes directly?

[Thimoteus]

I imagine we could keep a separate folder for each person, or even a branch for each person.

[kellhus]

I propose using the issue tracker to create issues for exercises and discuss them after you have attempted them on your own.

Grossly overestimating, Munkres contains at most $14 \times 6 \times 10 = 840$ exercises (chapters times sections per chapter times exercises per section). Compare that to more than 4,000 issues on the issue tracker of the IPython / Jupyter project. Hence the number of issues should be well within the manageable range.

Just create issues named "Exercise 2.10.4", label them "question" -- or should we create a separate "exercise" label for exercises? probably not, we'll want to edit both discussion and solutions into the final set of notes -- and if you are sure everyone has discussed it and / or the solution is correct and / or the deadlines have passed, go ahead and edit the main markdown files. Plus, as collaborators, we can edit each other's comments here (can we? I sure can see the pencil icon on everyone's comments; just edited @AddemF's comment above to merge two of his into one). Thus the parent post in each issue could contain a draft of the solution, which everyone can edit.

Plus, with the Chrome extension linked in the readme, we can utilize MathJax in the issue section as well.

We can continue work as time allows after our study-group deadlines have passed, too. Thus we can at some point close all the issues when the notes are done.

P.S. On the other hand, I think that discussion of and commentary on the main text should be added freely by everyone to the same master branch.
P.P.S. The guidelines, FAQs, scripts, and structure of the issue tracker can be re-used for other study groups we might want to have (the four of us or with other new people in the subreddit)! So this is not just a one-off effort in hammering this out. :-)