launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02580
Re: Clarifying our terminology
I understand Matthew's point, the terminology could be overwhelming to
new-comers, but I think I have a solution: have 2 separate
view/schema's for project registrations: a simple view and an advanced
view. Here in the advanced view we can keep all our favorite stuff :)
so basically no change for us and other projects who don't like our
work can choose a simple view that has less stuff and much simpler
terms. Coding-wise we just have to port some stuff around for the
views. We need to discuss this in a little more detail, what do you
guys think of my solution.
--
Regards,
Vikram Dhillon
~~~
There are lots of Linux users who don't care how the kernel works, but
only want to use it. That is a tribute to how good Linux is.
-- Linus Torvalds
On Fri, Feb 12, 2010 at 1:44 PM, Curtis Hovey
<curtis.hovey@xxxxxxxxxxxxx> wrote:
> On Fri, 2010-02-12 at 17:28 +0000, Matthew Revell wrote:
>> 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.
>
> Blueprints's terminology and workflow was designed for Ubuntu. It was
> never generalised and simplified for other projects to adapt. The
> language and workflow is also a barrier to Launchpad engineers.
>
>
>
> --
> __Curtis C. Hovey_________
> http://launchpad.net/
References