| 1 |
On Thu, 2022-06-16 at 18:06 +0000, Robin H. Johnson wrote: |
| 2 |
> A question I'd like the candidates to answer. |
| 3 |
> |
| 4 |
> What do you feel that Council can do to increase the contributions to |
| 5 |
> Gentoo? |
| 6 |
> |
| 7 |
> - how do you feel development velocity of Gentoo should be measured? |
| 8 |
|
| 9 |
I'll measure the following: |
| 10 |
- commit amount and frequency, if a person contributes already. |
| 11 |
- responsiveness on bugs.gentoo.org |
| 12 |
- community interaction: irc, bugtracker, ml, github, media (forums, |
| 13 |
reddit, etc) |
| 14 |
|
| 15 |
TLDR: if a person ignores bug-reports, bump-requests and general |
| 16 |
feedback, I would not consider those as a valuable contributor. |
| 17 |
Either retire, set devaway, or do the work. |
| 18 |
|
| 19 |
> - how do you feel technical debt of Gentoo should be measured? |
| 20 |
Not sure if it's possible to measure at this point. |
| 21 |
One has to be a pretty active member of developer community to actually |
| 22 |
see important things happening here and there. Maybe if we could |
| 23 |
introducde a special bug tag/category it'd have more visibility. |
| 24 |
|
| 25 |
> - how do we make it easier to get orders of magnitude more |
| 26 |
> contributors? |
| 27 |
|
| 28 |
We can increase number of contributions by paying more attention to |
| 29 |
github PRs, active GURU members and bugs with PATCHes. |
| 30 |
Not something council can directly influence, but it's something |
| 31 |
council can encourage. |
| 32 |
|
| 33 |
> - how do we make it easier to do QA on significantly more |
| 34 |
> contributions? |
| 35 |
|
| 36 |
I don't want to associate this particular member of developer community |
| 37 |
with the QA team, but some QA-related bug reports could use fine-tuning |
| 38 |
in a way those are reported. |
| 39 |
Internal politics is invisible to external contributors, but pretty |
| 40 |
much anyone can get this kind of QA report, even GURU contributors, and |
| 41 |
random publically accessible repos/overlays. |
| 42 |
|
| 43 |
For example, filing a bug as gentoo-ci would reduce perceived pressure |
| 44 |
and encourage more bug handling. |
| 45 |
I've reported this couple of years ago (see what I did here?) with no |
| 46 |
reaction: |
| 47 |
https://github.com/asarubbo/ci/issues/1 |
| 48 |
|
| 49 |
Releasing source code could also encourage more contributions and |
| 50 |
improvement of the ego-CI. |
| 51 |
I'd certainly would like to fine-tune some reports and maybe even |
| 52 |
disable some. |
| 53 |
https://github.com/asarubbo/ci/issues/2 |
| 54 |
|
| 55 |
> - what blockers do you perceive in the contribution processes, and |
| 56 |
> how |
| 57 |
> do you think they should be tackled? |
| 58 |
|
| 59 |
Inability of some members of dealing with github(tm) PRs is a major |
| 60 |
factor, unfortunately. |
| 61 |
|
| 62 |
Genrally council could encourage review of external contributions, |
| 63 |
maybe even organise a PR-bugday, dedicated to reviewing and merging |
| 64 |
github PRs. |
| 65 |
|
| 66 |
> |
| 67 |
> Many of the developers I nominated in my previous email to the |
| 68 |
> -project |
| 69 |
> list were because are the very prolific contributors or have |
| 70 |
> significant |
| 71 |
> impact in their contributors: how can we increase not just the |
| 72 |
> prolific |
| 73 |
> contributors, but get many more contributors everywhere? |
| 74 |
|
| 75 |
Council nominations, while is certainly is a popularity contest, also |
| 76 |
reflects community preception of candidate's abiility to voice and |
| 77 |
defend opinions. |
| 78 |
Finding leadership is always hard, but if we could encourage developers |
| 79 |
to share their opinions with community and not be afraid of judgement - |
| 80 |
we'd get more contributions and probably more council candidates. |
Archives