| 1 |
> > - Project status reports once a month for every project |
| 2 |
> |
| 3 |
> Totally agree on this one! |
| 4 |
|
| 5 |
OK. |
| 6 |
|
| 7 |
I'll give you Release Engineering's "status reports" for September, |
| 8 |
October, and November: |
| 9 |
|
| 10 |
September: taking a well-deserved break |
| 11 |
October: taking a well-deserved break |
| 12 |
November: taking a well-deserved break |
| 13 |
|
| 14 |
How about other projects that rely on things like upstream's release |
| 15 |
cycle? What about projects that just maintain ebuilds? |
| 16 |
|
| 17 |
Here's the games team's "status reports" for every month: |
| 18 |
|
| 19 |
"Fixed more bugs, added more packages, cleaned up some ebuilds." |
| 20 |
|
| 21 |
Now, perhaps what everyone would like, instead, would be status reports |
| 22 |
*where necessary* from certain projects? |
| 23 |
|
| 24 |
In fact, the council has been discussing asking a few projects about the |
| 25 |
status on some of their tasks. The main reason for this is for |
| 26 |
communications purposes. Basically, we'd just get a "Hey, where are you |
| 27 |
at on $x?" response from the teams. |
| 28 |
|
| 29 |
I don't *want* to drown projects in bureaucracy and paperwork. I want |
| 30 |
them to *accomplish* things, instead. |
| 31 |
|
| 32 |
-- |
| 33 |
Chris Gianelloni |
| 34 |
Release Engineering Strategic Lead |
| 35 |
Alpha/AMD64/x86 Architecture Teams |
| 36 |
Games Developer/Council Member/Foundation Trustee |
| 37 |
Gentoo Foundation |
Archives