Hi folks, Thank you, @Kenneth Knowles <[email protected]> and @Laura Alejandra Zanella Calzada <[email protected]> for the amazing work done so far.
I agree, to make this successful, it should be super easy to fill out. To pre-fill all the data fields, for the Outreachy program: 1. would it be a good idea to interview our Outreachy interns to record the steps they took? I think this will help us to model a common process that would be fast and easy to follow and rate. Also, we could leave an open space to fill out with the steps we didn't consider and are important for interns/mentors. Also, I would consider making one document instead of separate docs. We could add to the answers "not applicable" if that step wasn't taken. 2. For me makes sense to make two friction logs (one for mentors, one for interns) because mentors and interns face different issues because they do different tasks. 3. regarding the active monitoring role: Could someone give us an example of what we could do to review the incoming data to ensure the system itself (use and analyze)? could it be an example, extracting a report tasks of the project? See if a task is getting too long to be completed? Thanks, Katia On Wed, Nov 6, 2019 at 12:57 PM Shane Curcuru <[email protected]> wrote: > 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 >
