← Back to team overview

launchpad-dev team mailing list archive

Clarifying our terminology

 

I'm reading through the Bazaar versus Git discussion that the Drupal
community are having [1].

There are some interesting comments and I recommend you read as much
as you have time for. Several stuck with me and I'd like us to talk
about one in particular:

  Looking at Launchpad, I see a system that loves to throw weird terminology at
  me, blueprints, drivers, WTF? Especially its hard separation between
features and
  bugs, notion and treatment of "delivery" milestones, approvals and
assignments,
  busts the hell out of me. That may be suitable for your company's
business product
  development and perhaps understood by you and your co-workers after
having had a
  workshop or completing the Launchpad certificate™, but how does that
remotely apply
  to Drupal's flexible and successful usage of issues with various
transitioning states...?
  Implementation: Good progress? Of course.

The terminology we use in Launchpad has always struck me as one of our
biggest barriers for newcomers. I understand why we have some unusual
terminology: in some cases, we're dealing with concepts that don't
crop elsewhere or, at the least, aren't adequately described
elsewhere.

Even though we may have good reasons for some of our unusual terms, I
think they're a problem nonetheless. Should we consider changing some
of the less obvious terms? Or is there something we can do to make our
terminology and concepts instantly understandable to someone using
Launchpad for the first time?

I think mpt would be turning in his, erm, office chair were he to read
someone joking that you need a "Launchpad certificate" to fully
understand Launchpad.

1. http://groups.drupal.org/node/48818

-- 
Matthew Revell -- https://launchpad.net/~matthew.revell
Launchpad.net -- cross-project collaboration and hosting



Follow ups