1 |
Folks -- |
2 |
|
3 |
Over the past few months, there have been a number of ideas tossed around |
4 |
about having this or that feature available to the developers. Off the top |
5 |
of my head, I can recall: |
6 |
|
7 |
* shared calendaring |
8 |
* shared addressbooks |
9 |
* web mail |
10 |
* workflow management/project management |
11 |
* wiki (internal and/or external) |
12 |
* php support for developer ~/ directories |
13 |
|
14 |
and the list goes on. |
15 |
|
16 |
The thing is, most of these are being requested by one or two developers |
17 |
and I have no idea if the group as a whole wants or needs them. Do we want |
18 |
a full-blown groupware system like phpGroupWare and/or eGroupWare? Do we |
19 |
want to implement the Horde framework? Or are we happy with what we have |
20 |
now? There used to be a lot of wiki proponents out there, but the verve |
21 |
seems to have died down a bit. Do folks still want one? |
22 |
|
23 |
We're finally getting to the point where we have some hardware to start |
24 |
offering new features and capabilities. Now we just need to decide what. |
25 |
|
26 |
I have a feeling that this email is going to bring a deluge of responses |
27 |
about "we should have this or that" with little, if any, consensus. So, |
28 |
I'm going to be a bit ruthless in this. If you simply say, "we should have |
29 |
<some feature>, kthanx" and leave it at that, your request is likely to |
30 |
receive very little attention. |
31 |
|
32 |
If, on the other hand, you really believe we need some sort of capability |
33 |
and/or feature, then do your research, find the top 2-3 apps that provide |
34 |
that functionality, draw up the pros/cons in a summary of sorts and create |
35 |
a GLEP[1] for it. The other developers can discuss/vote on it and we'll |
36 |
take it from there. I don't promise to implement everything that gets |
37 |
voted up, simply because we need to ensure that all apps fit within our |
38 |
overall architecture, are secure, aren't resource hogs, etc. I do promise, |
39 |
however, to give those requests a lot more consideration than the "kthanx" |
40 |
requests. :) In this case, GLEPs speak louder than words. |
41 |
|
42 |
Some guidelines to consider related to our current infrastructure: |
43 |
|
44 |
* We (the infrastructure team) are responsible for supporting whatever new |
45 |
features that we (Gentoo) decide to implement. Thus, when it comes to |
46 |
deciding what does/doesn't get implemented on our servers, a very |
47 |
significant aspect of the overall decision making process is how easy |
48 |
things will be to maintain. Thus, suggestions that contain phrases like |
49 |
"and then write a series of custom modules to hook them all together" are |
50 |
far less likely to be approved than ones that contain phrases like |
51 |
"simply untar it, edit two conf files and it runs from there". |
52 |
|
53 |
* One thing I consider very carefully when implementing new applications is |
54 |
how well-supported they are in the OSS community. Apps which haven't |
55 |
been updated in over a year, have little activity on their mailing lists |
56 |
(or have no mailing lists) and do not have a strong community following |
57 |
are less likely to be approved. This is a *general guideline*, mind you, |
58 |
and not a firm rule. |
59 |
|
60 |
* Your participation in all of this is crucial. I realize we don't all |
61 |
have the time to research options, write up proposals, etc. Fine. But |
62 |
at least take the time to comment and vote on the other proposals that |
63 |
get put forth. I don't know what sort of infrastructure we want. I know |
64 |
what I want, but you all need to tell me (using the process above) what |
65 |
you want. Then, we can figure out what the best solution is for the |
66 |
entire team. |
67 |
|
68 |
--kurt |
69 |
|
70 |
[1] http://www.gentoo.org/proj/en/glep/ |