Kenneth Knowles wrote on 2019-11-5 10:49PM EST: ...snip...> We had some other ideas about how to make this useful: > > - mentor should write friction log on behalf of the intern (intern could > also write their own)
Allowing both seems useful; interns that get into the process will provide a much fresher perspective when using their own words. But mentors will often see issues the intern is facing, but isn't realizing is an issue, so those reports (which will probably be more specifically written about our workflows) will also be important. A big part of making this successful will be making filling out the friction log... super-easy. 8-) So ensuring it's a one-click start from any project using these is key. The way to get started needs to be in front of the people doing these in their working environment, and all the data fields should be pre-filled. Also: the header box for the "steps you took" is not clear - it looks like a rating scale, rather than a suggestion to rate each of the steps taken while writing the steps themselves down. The following example is better, it shows the clear progression, plus the fact they are rating each step. Having templates for a few common processes might help, although it would be hard to figure out which processes to model. > As I was making the document I had some new questions: > > - should mentors also write friction logs for themselves? (I think yes) Yes, because they face different tasks. > - do we expect many logs per internship, for different tasks? > - would a longer term "journal" be a good idea, like a friction log of > the entire internship? (might be easier for an intern to keep up with this > habit, not having to create a bunch of separate docs) Offer both ways, if possible. We're not going to know how each individual intern finds it super-easy to start these. Personally I'd find separate docs annoying; but I bet some people would simply report a single log, then forget about them until something else friction-y happens. > - should we (diversity@apache) take an active monitoring role so we see > some of what happens on Jira, code review, and mailing lists? (is this just > way too much?) Depends on the project(s) using them. Having D&I committee members able to review the incoming data to ensure the system itself is easy to use (and easy to analyze) is valuable - although it depends on volunteers available for it. -- - Shane Member The Apache Software Foundation
