Add doc sections for further development

[rivera-lanasm]

• Adding sections to Directory structure for further development
• Adding User documentation for using HPCC

Open to any comments/suggestions here!

[shapeseas]

Hey @rivera-lanasm this looks like a great starting point, particularly HPCC/UsePatterns. My one worry is in HPCC/UsePatterns as this repository is public. @markwhiting interested in your thoughts on where these sorts technical patterns should reside trying to balance accessibility and security.

[rivera-lanasm]

hey @shapeseas, are there security concerns here with respect to who can see these docs?

[markwhiting]

I don't think there are any major security issues that I see in this, but we should keep in mind that this is intended to be public, and anything that needs to be secret should be dealt with differently (perhaps that's something that we need to think about too at some point)

As a rule I think we should also lean away from abbreviations whenever possible and for something like this repo, I'd lean on naming that is designed for humans to read, e.g., spaces not snake or camel case.

[rivera-lanasm]

@markwhiting, I agree with all that. I hope the notes I'm adding in the documentation don't seem too project-specific. How I see it, documentation for processes that involve multiple projects by design (like Surveyor and other MTurk utilities) should be placed here rather than in a specific project repository if that documentation might be useful to other projects as well.

@TutiGomoka, adding you here in case I missed anything in my notes from our conversation about how payments are currently handled for the empitica-deliberation project. I wrote these to MechanicalTurk/WorkerPaymentProcess.md.

@JamesPHoughton, adding you as well, as you mentioned you were interested in learning more about payment process for empirica-deliberation.

[markwhiting]

@rivera-lanasm I think that's ok, but, I think I would assume that other people don't know much about a specific project setting, and it might be important to capture that a little. So for example, instead of "how we solved A for project B", something more like "how we solve A when a project has properties X, Y ,and Z (like project B)".

I also think that as much as possible, I would try to centralize any tool specific steps so as to not have repetition of that kind of thing. Not sure exactly how that would play out here, and for example, when we might want to have tool specific steps at the tool repo readme instead of here, but I just think that's something for us to think about at a higher level.

As a side note, what do you think about paths and file names with spaces, and no paths based on abbreviations (e.g., HPCC?) — I don't hold a super strong belief here, but I think we should be consistent, and I feel like the main goal of this repo is to be human readable by people we may never meet. So I would rather we don't make too many assumptions about what they know etc.