This was discussed at our meeting on January 30 2017.

Tasks:

• @skamath - make a list of public facing sites that would potentially act as entry points for new contributors
• @ankursinha - speak to various web ninjas to ascertain what metrics we should collect for the audit

@robyduck , @shaiton, @duffy - would you folks have some advice on what volunteers should look out for when going over our webspace? Should we also try to collect feedback from users, for example?

Is the context here that you're trying to gather data for Join, or that you're trying to redo our websites? Because I'd argue the latter is in the scope of the websites team. Yet your "Why" statement above seems to include both. I would suggest if you want to take the broad approach that the work is done in the websites team, not in join.

I ask because in order to advise I need to understand the context.

While I hope we'll find more volunteers to work on this, as it stands, we have only enough hands on board to work on the smaller tasks of gathering data for join and identifying entry points for newbies.

If, in this process, we can gather data that would also help the websites team make broader changes when they look to make them, we'll be happy to collect it and pass it on - as you correctly say, the broader task falls within the scope of the websites team, not the join team.

(Updated the ticket description)

Okay great, thank you for the clarification!

What I would suggest is defining some user scenarios you want to test:

• I'm a developer and want to help write web app code for Fedora.
• I'm a writer and want to help Fedora by writing.
• I'm a designer and want to help Fedora by making designs.
• I'm a translator and want to help Fedora by translating my language.

So on and so forth. Define the user scenarios you want to test. Then assign each scenario to a volunteer, and ask them to test that scenario. There's a few ways you could do this:

• You could keep it totally open (which is more real-world TBH) and tell them to just do it. They will probably end up relying on a search engine or asking around, which again is more realistic but might be more challenging.

• You could direct them to start at getfedora.org (or join.fpo, or wherever) and go from there. It's a less realistic way to do it but at least gives them a clear first step. The big assumption in this kind of testing is that the real world users would make it to the site you're having the testers start on.

Have the volunteers keep a log of every action they did, every site the visited, whether or not it was useful, any doubts or successes they had, etc.

Then we could do data analysis on the logs afterward to identify issues in onboarding via the web for the scenarios you tested, and brainstorm some ways to address those issues (I would suggest doing the analysis / brainstorm in concert with the websites team.)

These tickets may also be a good read:

https://pagure.io/Fedora-Council/tickets/issue/70
https://pagure.io/Fedora-Council/tickets/issue/82

I believe commops, marketing, and magazine may be good to consult with as this project moves forward in addition to the already mentioned websites.

Newish here (so I've recently had the experience of attempting to "join").

Is this issue more about the initial entry point? (i.e. from where do people who contribute normally start?) or is it more about the process by which people weave to contribute?

In general (from the outside) Fedora seemingly has the most blatantly welcoming "join us" message throughout (and is why I switched to using Fedora), but trying to actually contribute to Fedora (at least from a design perspective) involved a tangled process that I'm still not entirely sure I could replicate―even after contributing a couple of things.

If this is about the process side of this (how can/does a person move from wanting to contribute to contributing) I'd love to be involved in some way. It's fresh for me and I'd like to make it easier for others (and better understand it myself). And if it's not, let me know if I can assist in some other way.

@ankursinha Hey, how would you advise @kylerconway - do you want him to start an eval using one of the use cases I suggested? I'm happy to mentor him through the eval process. Let us know what the plan is here.

@kylerconway , @duffy - sorry, missed the ticket notification before.

@duffy - Sure, please go ahead. I was going to point volunteers to your use cases anyway :)

Let me know how to begin. Thanks.

Just a quick update that @kylerconway has been working on this, I've been mentoring him on it, he's working on the Design use case. We need folks to help with the other use cases but I think @kylerconway 's work is really impressive and would serve as a great model for other volunteers to follow.

thanks @duffy! once I'm able to get everything finished 'll post for feedback here and try to do a writeup that could serve as a general guide for other like-projects.

hey @kylerconway - any updates on this one?

I've been in the middle of a job transition but I'm still working though it. Would it be best to post what I have now for commentary or keep pressing on to completion? I know you've seen a version of it in draft form. Whatever would be most helpful. I suspect there are useful elements already, but I'm new to the concept here so I could be wrong.

Hello everyone! To see what I've completed so far take a look at this link and work your way through. I decided to use Sozi for this, which (as I noted elsewhere today)

really made me re-evaluate the actual mental steps I had to take (and re-take, and Déjà vu) because it takes time to design the mental process I had when going through it the first time. That allowed unnecessary, redundant, and confusing steps to be abundantly clear (and frustrating).

As this is my first attempt at this sort of thing please do provide any and all feedback about whether this was useful for your purposes.

I found this very helpful and it clearly illustrates some of our pathway problems. One thing I like about this presentation is that it makes it clear we need to think through process and architecture not tools.

Thanks, Bex.

Thanks @kylerconway. I'll close this now that it's been done. I'll add it to one of my Fedora-Join update blog posts so that it shows up on the planet for the community to read too.