| 1 |
On Thu, Oct 6, 2016 at 3:45 AM, NP-Hardass <NP-Hardass@g.o> wrote: |
| 2 |
> What are we going to do if my Project |
| 3 |
> MATE which has only me as a project member and lead and I am slacking? |
| 4 |
> Can you truly force me to do something? The only real punishment you |
| 5 |
> can give me is to kick me, and what does that do? It makes all MATE |
| 6 |
> users suffer because they now have 0 developers instead of 1. The real |
| 7 |
> way that you affect change is by getting involved in a project, not |
| 8 |
> yelling from the sidelines (eg external parties telling a project how to |
| 9 |
> operate). |
| 10 |
|
| 11 |
++ to your post in general. |
| 12 |
|
| 13 |
I just wanted to say that GLEP 39 already recognizes that there are |
| 14 |
situations where there are conflicts between the needs of a project |
| 15 |
and the needs of the distro, and this is basically the original |
| 16 |
purpose of the Council. I believe Debian uses a similar approach. |
| 17 |
|
| 18 |
Sure, you could turn all these issues into general referendums but I |
| 19 |
don't think this is productive for a couple of reasons: |
| 20 |
1. There are usually 1-2 substantive topics in a typical monthly |
| 21 |
council meeting and this would be a lot of voting. I actually do |
| 22 |
think that the average developer is able to weigh the sorts of issues |
| 23 |
that you bring up, but I'm not convinced that most would actually read |
| 24 |
up on 50+ post threads every time something comes up. |
| 25 |
2. Today when there is a council agenda topic we tend to have |
| 26 |
discussion threads about the topics, but people don't feel as beholden |
| 27 |
to argue the points to death because in the end they trust the council |
| 28 |
to do the right thing. If they're all left to general votes I suspect |
| 29 |
there would be more churn. |
| 30 |
3. How do you decide when an issue is allowed to trigger a general |
| 31 |
vote? The Council basically sends out a call for agenda items, and |
| 32 |
can give as much or little time to a topic as it deems appropriate. |
| 33 |
So, if something is silly it can get settled in 5min. I really don't |
| 34 |
want to see trivial topics triggering votes every month from the whole |
| 35 |
dev community, or people asking Comrel to go after people for bringing |
| 36 |
up topics they think are trivial, and so on. Today anybody can have |
| 37 |
their day in front of the Council if they wish, and it tends to not be |
| 38 |
a problem. Maybe it wouldn't be a problem with a referendum, but it |
| 39 |
generally ramps up the impact to deal with anything. |
| 40 |
|
| 41 |
Right now I think the Council is largely handling these situations as |
| 42 |
well as can be done short of having a budget to hire people to do |
| 43 |
directed work (the Foundation actually did do that once that I'm aware |
| 44 |
of, at fairly low cost, with mixed results). For the most part we |
| 45 |
recognize that we have a lot more power to say "no" than "yes" because |
| 46 |
"yes" requires people to do the work. Usually we try to focus on |
| 47 |
clearing barriers to things getting done and draw boundaries when |
| 48 |
there is conflict, keeping the touch as light as possible. We can all |
| 49 |
point to things that didn't turn out how we might ideally envision |
| 50 |
them, but typically this is more the result of nobody stepping up and |
| 51 |
doing something we want to see done. For example, the Council can do |
| 52 |
things like adjust the lines between bug wranglers, maintainers, |
| 53 |
security, and arch teams, but we can't make people step into any of |
| 54 |
those roles. |
| 55 |
|
| 56 |
-- |
| 57 |
Rich |
Archives