Page MenuHomePhabricator

Gather and Analyze Information Around Developer Tooling Woes
Open, NormalPublic


The developer satisfaction survey is a good place to start getting a broad idea of what problems developers face, but results may not be detailed enough to hone in on the specific problems faced by both staff and volunteer developers when they work. Conducting interviews or observing developers work could help us gain deeper knowledge about what they feel is most counterproductive about the current developer environment.

The outcome of this task should be collected data, qualitative and/or quantitative analysis, and defined problems to be solved as a result of the analysis.

Event Timeline

jeena created this task.Dec 20 2018, 7:56 PM
jeena triaged this task as Normal priority.
jeena updated the task description. (Show Details)Dec 20 2018, 8:07 PM
jeena added a comment.Jan 17 2019, 8:13 PM

On Jan. 8, I sent an email to the engineering and wikitech-l mailing lists to solicit participants for interviews on their local dev environment.
There was some valid concern on not being able to reach many volunteers in other countries through this method. Thankfully there has some amount of volunteer participation, and I've asked volunteer participants to spread the word to their counterparts. We will continue to keep the volunteer experience in mind in future information gathering steps.
I expect to finish up most interviews by the end of this week and proceed to start the analysis step.

brennen added a subscriber: brennen.Feb 4 2019, 5:29 PM
jeena added a comment.Mar 7 2019, 10:41 PM

Analysis was completed and results were posted as well as emailed to engineering and wikitech-l:

The following rubric has been created for the local development environment:

Must have documentation that is easy to access
Must have documentation that is easy to follow
Must have documentation that is up to date

The documentation must define clear standards for developers whenever possible

Basic install must be easy for anyone

	Should take 30 minutes or less
	Should require 5 steps or less

The environment must be easy to configure, use, and share

	Configuration must have sensible defaults that result in a running environment
	Configuration should be in one place
	New environment spin-up should take 30 seconds or less
	Changs to code should propagate almost instantaneously
	Access information should be output to the user

The basic environment should not tax the resources of an average laptop

	(specification to follow)

The environment should match production more closely

	The environment must be docker based
	Local test results must be equivalent to CI
	The environment must be able to deploy using images built in CI

We have started work on a local dev environment that runs in Kubernetes (