[TEAM] Vote on changes to the meeting structure

flocculant at gmx.co.uk flocculant at gmx.co.uk
Fri Oct 16 23:10:34 UTC 2015


On 17/10/15 00:08, Pasi Lallinaho wrote:
> On 2015-10-17 01:47, flocculant at gmx.co.uk wrote:
>> On 16/10/15 21:13, Pasi Lallinaho wrote:
>>> Since the meetings have been far apart, and not many people have 
>>> been around, let's do the voting on the meeting structure changes on 
>>> the mailing list. Here's the proposal again for clarity:
>>>
>>>
>>> 1) Stop running the "Team updates" section
>>>
>>> Pasting the updates in a meeting means more work (through having to 
>>> memorize/note down items) for contributors. It also means that those 
>>> who can't attend the meeting (which means many people per meeting), 
>>> can't paste the updates unless somebody does this for them.
>>>
>>> Since we now have a timeline tab [2] in the tracker, most of these 
>>> updates can be seen live.
>>>
>>> The only real change in action contributors would need to take would 
>>> apply to work items. Practically this means that everything that 
>>> could be worth mentioning for people outside the team - or added in 
>>> the release notes - should be in the blueprints. Doing the updates 
>>> like this also improves their findability. As I see it, this isn't 
>>> much different from what we currently do, or at least what I try to do.
>>>
>>> Finally, the updates that aren't worth/important enough to add to 
>>> the blueprints could still be shared in the meeting, thus...
>>>
>>> 2) Rename the "Announcements" section to "Updates and Announcements"
>>>
>>> This is just semantics, but it should be done to avoid confusion and 
>>> be more accurate.
>>>
>>>
>>> Team members, cast your vote by sending +1, -1 or +/-0 on this list. 
>>> If you wish to vote privately, you cand send a mail to Simon or me 
>>> (you'll find the emails - or can ask on IRC).
>>>
>>> We'll have a week for the votes. The results are gathered and 
>>> published after next Friday (or after 21UTC next Friday) when me and 
>>> Simon crash on IRC at the same time.
>>>
>>> Cheers,
>>> Pasi
>>>
>> The other side of this being - how long do we wait as a team for 
>> members of that team to vote?
>>
>> I see no reason why we'd not be good to expect a response for 
>> something 'less important' as no more than a month.
>>
>> For something that has importance to Xubuntu as a whole I would 
>> expect some response somewhat faster - even if that response was 
>> 'foo' caught me on the phone, I'm not able to vote, my feeling is 
>> *this*'
>>
>> Thus we can take into consideraration people's POV.
>>
>> example - there are 14 (currently) of us
>>
>> we have a vote, two of us are awol (ish), team is 14
>>
>> vote gets taken and stands at 6 +, 6- with 2 to vote, 1 does, the 
>> second does *life* stuff*
>>
>> at 2 weeks, the vote is now 7+,6- and the vote carries
>>
>> just thinking aloud here - but how long should a team wait for one of 
>> it's members before making that member's vote null, you have to bear 
>> in mind here the length of a support cycle, at 6 months should we 
>> wait for someone taking 4 months to make a preference?
>>
>> just a thought, provocative perhaps, but just a thought ;)
>>
>>
>
> If the vote result was that close, it would most likely warrant 
> further discussion and not carrying on with whatever was voted on. If 
> it's important, and several people haven't voted after the set 
> deadline, then we should consider what would be the best way to either 
> try to get a hold of them - or resolve the issue without them.
>
> Just my two cents,
> Pasi
>
wfm

I'd just be concerned about stagnation is all





More information about the xubuntu-devel mailing list