Skip to content

Publishing results of MDN Short Surveys #9

Open
@dontcallmedom

Description

@dontcallmedom

WebDX has already helped with designing and launching 2 short surveys on MDN:

  • one on which browsers developer are paying attention when deciding to use a feature
  • one on their interoperability need around proposals made for Interop

I expect further MDN short surveys to follow suite. The policy they run under allows for making the results public.

There are 4 levels of publicity we can consider for these results:

  1. make the raw data public on a case by case basis (e.g. if we assess they provide easily interpretable data and low risk of misinterpretation)
  2. make the raw data public in all cases, but with an editorial interpretation and communication on a case by case basis
  3. raw data and interpretation in all cases, but with communication efforts on a case by case basis
  4. raw data, interpretation and communication in all cases

My sense from the people involved in the first 2 surveys was that (2) was the minimum we should consider (which I agree with); ideally, I would prefer (3) (i.e. we always provide an interpretation, even if that interpretation is to the effect of "we think the question was wrong" or "we don't understand this"), but this requires a greater commitment than what we've discussed so far.

I don't really see a reason why we should go to (4) - if the interpretation of the results is that the survey was lacking in one way or another, it's a useful learning, but not one that we need to expand outreach capital on IMO.

As a starting point, I suggest we publish the content of the survey itself, the metadata on its running (period, MDN pages it was displayed on, percentage of page views it was displayed on) and the raw results as CSV data of MDN short surveys on this repo in a dedicated folder; I would then seek volunteer to write up an interpretation for review by the group; if there is no volunteer or if we can't get agreement on such an interpretation, this would probably be a sign that (3) is unlikely to be achievable.

Thoughts?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions