jdcasey

These are my initial thoughts, to get the discussion started. Obviously, this is nowhere near being ready (especially WRT formatting).

Though some of this will seem fairly formalized, I'm mostly interested in focusing on the concepts behind the questions, at least at first. Once we've decided on the information we want to gather, we can talk more about the formats we need to use in order to extract that information effectively.

What do we want to know about Maven users?

  • Basics about their tooling and application platform
  • Feelings on importance and quality of features
  • "Demographic" information, such as team size, organization size, etc.

Thoughts about how to administer the survey

(many of these are incorporations of Jesse's initial feedback):

  • Tools / Platform

Mainly checklists of different technologies they're using.

  • Feature / Usage rankings

Probably make broad use of http://en.wikipedia.org/wiki/Likert questions, and let feature priorities percolate out of the aggregated ratings.

Some questions might be radio-button, to categorize into broad usage classes.

  • Demographic information

This will probably consist of radio-button or yes/no questions, to help get a rough idea of the groupings of people who may be oriented on the same set of POMs...

Question Areas

Tools / Platform

What platforms are common for Maven users?

  • JDK (java version and vendor)
  • OS: Windows / Linux / OS X / Solaris / ???
  • IDE: Eclipse / IDEA / NetBeans / ???

What technologies do you use in your applications?

*web UI
*web services
*XML
*databases
*code generation
*mobile architectures (J2ME)
*JMS
*EJB
*RMI
*CORBA
*JNI

What programming language(s) do you use in your applications?

*Java
*Net
*C / C++
*Ruby
*Python

What build technologies are these people using? Are they converting? Would they like to?

*Ant
*Maven 1.x
*Make
*Maven 2.x
*Shell / Batch scripts
*IDE

Feature / Usage Rankings

How advanced is your usage of Maven?

*requires no customization of the POM beyond basics: identity and dependencies
*requires some configuration of pre-existing, default mojos in the lifecycle
*requires binding of non-default mojos to the lifecycle
*requires development of custom plugins

Do you use Maven to generate project reports and/or websites?

*reporting
*website

Rate the importance of each of Maven's features: (1-5 rating Not Important -> Very Important)

I actually need some help listing them all here. Just the broad feature categories...

Artifacts and Dependencies
*Transitive Artifact Resolution
*Snapshot Artifact Support
*DependencyManagement

Lifecycle and Plugins
*Build Lifecycle
*Versionless Plugin Configuration
*PluginManagement
*Plugin Prefix Support (maven-jar-plugin:jar -> jar:jar)
*Plugin Multiple-execution Support
*Java Plugin Support
*Ant Plugin Support (Ant as a plugin language, not just the antrun plugin)

POM
*Multilevel Inheritance
*Build Profiles
*Interpolation

Website, Documentation, and Community Support
*User's list
*Website
*Site Documentation
*Embedded Documentation / Help

Etc.

Rate each of Maven's features according to how well you feel they work: (1-5 rating Not Good -> Very Good)

This is an attempt to identify which areas of Maven need the most attention, according to the pain caused to users. The wording is feeble.

See feature list above.

Other Questions...

jdcasey

I'm not quite sure how much of this has been duplicated above. I'm leaving this here, since some of it has more detail than the above list(s), and may reflect subtle but important differences in the questions being asked...

What are the most painful parts of Maven (most dire need of fixing)?

*configuration problems
**proxy configuration
**authentication / wagon configuration problems
*lifecycle limitations
**plugin ordering
**plugin configuration
**plugin suppression
**aggregation problems
*project loading / inheritance
**parameter expression support
**POM encoding
*user feedback
**poor error messages
**hard-to-read output
**lack of diagnosis / direction to correct errors
**lack of embedded help information (manpage or SVN style)
*artifact resolution
**transitive metadata issues
**repository performance issues
*versioning maintenance on project hierarchies
*lack of documentation
*lack of developer-tools support

What features of Maven are you particularly happy with?

*transitive artifact resolution
*the POM
*build lifecycle
*plugin availability
*site / report generation
*community support

Which areas of Maven would you like to see new features for?

*more plugins
*assembly support
*project inheritance / workspace
*artifact resolution
*site generation
*lifecycle configuration
*expanded development cycle support (functional/integration testing, releases, etc.)

Demographic Information

How many developers work on the same application / project with you?

*5 or fewer
*6-15
*16-25
*26-35
*more than 35

How many developers are involved with maintaining your Maven builds?

*1-2
*3-6
*6-10
*more than 10

How many developers in your group use Maven directly?

same list as number of developers above

How many POMs does your group maintain?

*5 or fewer
*6-25
*26-50
*more than 50

Other Points:

I'd like to try to reach out to people who have made the decision NOT to use Maven, and find out why. In many cases, I've found that relatively simple fixes would lure a user back for a second look, and maybe even convince him to switch to Maven.

I'm not sure how to work this into the survey, because you're dealing with a class of people who probably don't have much patience with the Maven project. Therefore, you want to avoid asking them irrelevant questions (usage questions, for example). At the same time, if we have a section of questions for these estranged potential users, we should avoid exposing our loyal user-base to them, unless there is value in having both sets answer.

Also, whatever else we do for these people, we need to provide a place for them to give free-form feedback on their reasons for avoiding Maven.

Questions I'm interested in having answeres by the Estranged Potential User

Why are some potential users choosing NOT to use Maven?

*transitive metadata quality issues
*repository performance issues?
*lack of understanding of one or more parts

    • lifecycle concept
    • 1:1 artifact:pom
    • default-enabled testing
    • other?
      *lack of flexibility where reasonable
    • non-standard versioning schemes
    • non-standard project layout
    • dependency-usage classes (scoping)
      *lack of platform support
    • missing plugins
    • doesn't support target language concepts
  • No labels

1 Comment

  1. Brett Porter

    this looks good to me.

    I'd be more specific on the platform questions:

    • what platform(s) do you develop on?
    • what platform(s) do you deploy team infrastructure to (continuum, repository manager)?
    • what platform(s) do you target (deploy to)?
    • as above for JDKs

    Then in addition to what they currently use:

    • would you be able to use Maven if it's minimum requirement for running was Java 5 (but you could still build applications for JDK 1.3 and above)
    • would you be able to use Continuum if it's minimum requirement for running was Java 5
      (in both cases, give the option "I don't use Maven/Continuum").