User analysis

[joshbruce]

Marked version: 0.3.17

Markdown flavor: n/a

Proposal type: other

What pain point are you perceiving?

Who are they? Seriously. Historically, based on the PRs, I think this is what I'm seeing from my UX world.

1. Polyglot: This could cause a lot of communication difficulties; therefore, patience is critical.

• The header id issue mainly seems to affect Asian character localizations.
• GitHub user handles and names point toward users in Russia and Italy.
• Primarily the traffic on GitHub is in English.

2. Didn't ask for this (just example personas):

• My name's Jim, I'm a retired software engineer from way back. A friend of mine asked me to take over their site. I've been out of the game for a while now and wanted something to do on the weekends to keep my mind fresh and it seemed easy enough.
• My name's Adeline, I recently graduated from a developer bootcamp and am at my first job. I'm trying to maintain a legacy site. I didn't even know marked existed.
• My name is Jhumpa, I'm a recent college graduate. One of our projects was to create an NPM package and make it open source. I created a markdown editor that uses marked. Now I have a full-time job and can't really maintain it and its dependencies.

Experiment:

1. Close 60% of issues and PRs.
2. See who responds.
3. What they're response was.

Results:

(I didn't spend the time to keep track, this is one of those after the experiment to try a different experiment deals.)

• ~80% never responded.
• ~15% were pretty fine with it, they had walked away from marked long ago.
• ~4% were a little disappointed but understanding of where marked was and was trying to go.
• ~1% were very upset (only one actually took action to submit a proposal PR but ran into some trouble with understanding the test harness)

What solution are you suggesting?

• Create form letter to dependents
• Committers go to their dependents who depend on marked and post an issue containing the form letter (see who responds).
• Once the dust settles, determine if further experiments are required.

[UziTech]

We could automate the process. Get a list of dependents from npm, use GitHub API to add an issue with the form, see who replies.

[joshbruce]

I like it. Maybe we should scale back the initial requirement??

Just see what the version declarations are in package.json. Then target the ones with latest (*) - hopefully it's the smallest sample returned...thinking they're the ones who need to know the most.

[joshbruce]

Maybe a sub-issue of this epic assigned to the "Improved product scope" project...??

[styfle]

@joshbruce Can we close this issue now that there is a separate tool created to solve this problem?

[joshbruce]

@styfle: The epic is a larger goal or problem. The tool covers dependents, which are packages that happen to use Marked. This is broader like @Martii, for example, and how he uses Marked...and doesn't necessarily appear on the list of dependents.

[Martii]

That's because we are the equivalent of the "End User" (or top level node package that aggregates all others) and our Org is definitely private so npm/npmjs.com won't be showing us at this time. Part of examining a dependency is to determine it's privacy policy. If it conflicts with any of our terms without an opt in/out we prefer not to utilize it. npmjs.com only shows how many downloads typically for this use case. There could be others like us but not OSS as well.

This issue is a bit greek to me as I'm my experience is practical not theoretical so I hope I'm not babbling on too much. :)

[joshbruce]

@Martii: Agreed on the "end user" piece. Might be nice to have a survey or something; so, thank you for jumping into conversations where you can.