Hi folks, - I think it would be a very good idea to interview the Outreachy interns to have a better overview of the necessary fields of the friction log template and to perform any updating if required.
- Also, I think having an open space could be very useful in order to, as Kation mentioned, include steps, information or notes that weren’t taken into account in the template. - The idea of having one single document having the option of “not applicable” if it’s the case seems more efficient to me, being able to have better control. Thank you, Laura On 2019/11/06 13:21:59, Katia Rojas <[email protected]> wrote: > 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 > > >
