| 1 |
On Friday, January 20, 2017 11:21:07 AM EST Kent Fredric wrote: |
| 2 |
> |
| 3 |
> Right. I suspect we're probably closer to the same page than we think |
| 4 |
> overall, just your initial statements seemed to give me the wrong subtext, |
| 5 |
> and I wanted to steer clear away from it. |
| 6 |
|
| 7 |
The more you understand the intent and context you will likely find yourself |
| 8 |
more on the same page. Just read the GLEP its pretty simple. |
| 9 |
|
| 10 |
> There will still be a person or persons submitting data, and there will |
| 11 |
> be a person or persons receiving and collating that data. |
| 12 |
|
| 13 |
That should be up to each project, ideally the team lead but that is up to |
| 14 |
each. Who in the project creates and submits the report to council is moot. |
| 15 |
|
| 16 |
> All my framing concerns itself with is assigning the responsibility for this |
| 17 |
> interaction towards the recipient, and making it clear from the nature of |
| 18 |
> the interaction that feedback is regularly wanted, but not mandatory. |
| 19 |
|
| 20 |
I am suggesting projects should have a mandatory requirement to provide |
| 21 |
monthly status. If they meet, they have this already in any minutes or log. |
| 22 |
May require a summation. If they do not meet, someone can gather the info up |
| 23 |
to each project/team. It would take considerably less time for someone on the |
| 24 |
project/team to provide a summary. Than for another person to come poll each |
| 25 |
person in the team for the same information. It will take less time to come |
| 26 |
from within. |
| 27 |
|
| 28 |
I am not suggesting or discussing penalties. I would simply hope that saying |
| 29 |
something is mandatory. People understanding it has VERY minimal requirements |
| 30 |
and overhead. That they would understand the benefit and be onboard so its not |
| 31 |
a big deal. |
| 32 |
|
| 33 |
No reason to make it into a big deal and go off on punishment, etc. I hate |
| 34 |
that line of thinking. I rather people understand the benefits and partake |
| 35 |
because of such. |
| 36 |
|
| 37 |
> By "displayed in bulk", if I was unclear, the idea was to be able to have a |
| 38 |
> global "Gentoo Right now" status page where one could just skim-read through |
| 39 |
> all the given statuses, ( maybe sort them by freshness ) |
| 40 |
|
| 41 |
Which again this could feed into that. You will still need some brief info on |
| 42 |
each project. Again easier and more efficient to come from within than poll from |
| 43 |
outside involving more people and time. |
| 44 |
|
| 45 |
> Commit stats could be displayed on the side, but I wouldn't consider them |
| 46 |
> the most important part of this design, it would just be a bit of polish |
| 47 |
> on the finished product, mostly because the signal it gives from the |
| 48 |
> overview of all of gentoo is very weak, and doesn't really tell you much |
| 49 |
> more than "alive/dead" ( and of course, not all projects even have commit |
| 50 |
> data ) |
| 51 |
|
| 52 |
Commits show activity but not much more. Thus you need to speak to someone or |
| 53 |
have them provide information on what they and others they work with have been |
| 54 |
up to. It is not much. |
| 55 |
|
| 56 |
-- |
| 57 |
William L. Thomson Jr. |
Archives