1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
================
Launchpad Values
================
Whenever we are thinking about what Launchpad should be, or how we should
implement a change, or whether something is a good idea or not, we have
recourse to three distinct sets of guidelines.
The first is :doc:`strategy`, which reminds us why we are making Launchpad and
helps us answer questions such as "How does this help Launchpad meet its
goals?". The second is :doc:`scope`, which helps us answer questions like "Is
this in scope?". Together, they sort out the 'matter' of Launchpad.
The third is this document, the Launchpad Values. It tries to address the
'manner' of Launchpad. It, perhaps, will not answer specific questions for
you. Rather, it will rule out certain options and decisions before they are
even considered.
Like the :doc:`strategy`, this document is living: it should be changed and
improved as we learn more about how to make Launchpad. It is also
aspirational: not all of Launchpad lives up to these values.
Better tools help
=================
Launchpad is fundamentally based on the principle that improving the tools
that we use to make things will help us make better things than we could
before and indeed make better things more cheaply than we could before.
Launchpad should be that "better tool" and be always aiming to smooth and
accelerate the process of making software.
Invisible. If not, fun.
========================
Launchpad is a tool to help busy people get important stuff done. It should
stay out of the way where possible. Bugs, OOPSes, downtime and slowness all
draw attention to Launchpad and away from the interesting problems that our
users are trying to solve.
Where it is not possible to stay out of the way, Launchpad should be fun to
use. We make next actions obvious and draw attention to users' achievements.
Example
-------
When a branch is merged into the trunk of a project, that's generally the end
of its story. Launchpad quietly and silently detects that it has been merged
and marks the branch and any merge proposals as such. The branch then no
longer appears on default listings.
Reveal opportunities
====================
One of the grand things about open source software is that it is open to
contributions from total strangers.
Launchpad makes those contributions possible by removing as many barriers as
possible to contribution, and highlights areas where contributions would be
especially welcome.
Example
-------
When you click the Translations tab of a project that's translatable, you see
a list of all of the languages you speak, together with a progress bar telling
you how much translation work is available. You can click a language and
start translating right away.
Not our data
============
The data in Launchpad does not really belong to us, we are merely its
stewards. We make sure that users can get their data easily and that they can
change it as they see fit.
Example
-------
You can access almost all of the data in Launchpad through the RESTful APIs.
Not just their data
===================
The data people store in Launchpad doesn't just belong to them, though. It
also belongs to the wider open source community. The data needs to be used to
link between other projects, and to allow Launchpad to act as a front-end of
open source.
Example
-------
Someone who is not actually a maintainer of a project might register that
project on Launchpad so they can import code or synchronize bugs or so forth.
If the project's actual maintainer comes along and wishes to take it down, we
will *not* do so.
Cross-project consistency
=========================
If you know how to contribute to one project on Launchpad, you ought to be
able to quickly and painlessly contribute to any other project on Launchpad.
Or, if you can't, it won't be Launchpad's fault.
Example
-------
You can get the trunk branch for any project with 'bzr branch lp:project', or
the source for any Ubuntu package using 'bzr branch lp:ubuntu/project'.
All of open source
==================
Any open source project ought to be able to host itself on Launchpad. We do
not enforce workflows, rather we allow people to fit their project's existing
workflow into Launchpad.
However, when we can, we encourage people toward best practices. After all,
we want to make open source software better.
Example
-------
Launchpad separates whether or not a reviewer approves of code from whether or
not a branch is approved to land.
All users are potential contributors
====================================
One of the glories of open source is that any user is a potential
contributor. Launchpad guides new users toward the ways where they can begin
to contribute.
Close the loop
==============
Something magical happens when a feature or a workflow reaches all the way
back to where it began. The feature begins to re-inforce itself, and make
things possible that weren't possible before.
Another way of thinking about this is that the value is in the output, and
Launchpad is always concerned with the output of all of its features.
Example
-------
These are examples of where we aren't there yet.
Being able to attach patches to bugs is great, but it's not good enough until
developers can easily *find* those patches. Finding the patches is only good
enough when you can merge, comment and reject those patches.
Likewise, importing translations from an upstream is great, but it becomes
much, much better when those translations can be improved in Launchpad and
then sent back to the upstream.
References
==========
* :doc:`strategy`
* :doc:`scope`
|