diff options
Diffstat (limited to 'decisions/summary-20080814.tex')
1 files changed, 165 insertions, 0 deletions
diff --git a/decisions/summary-20080814.tex b/decisions/summary-20080814.tex
new file mode 100644
index 0000000..cd736f5
--- /dev/null
+++ b/decisions/summary-20080814.tex
@@ -0,0 +1,165 @@
+\agendaitem{Unplanned topics}
+\index{council!meeting!default proxies}
+All the council members should nominate default proxies.
+\agendaitem{Reactions to dev banned from freenode}
+I'd like to ask Council to discuss possible reactions to our developer
+being banned from Freenode without providing us with a reason. ... It
+would be good if Council officially protested against that ban and
+demanded a detailed explanation from Freenode staff.
+20:14 < Halcy0n@> Do we have a history of how many times this has happened?
+ I believe another dev was klined after this was initially
+ brought up.
+20:14 < musikc > ive spoken with the second dev actually
+20:16 < musikc > the guy said he'd done what he was told to do and was still
+ waiting for some resolution
+20:17 < musikc > i last spoke to him on the 10th
+\agendaitem{Moving meetings to a location we control}
+I want Council to consider moving their meetings somewhere where third
+parties can't control who in Gentoo can attend and who can't. Like our
+own small and created just for this purpose IRC server.
+20:26 < Cardoe > We already have a public ML where predominately a lot of
+ the discussion takes place. Is there really any actual
+ supression occurring because of our use of Freenode?
+20:26 * jokey is still not in favour of running an irc network
+20:27 < dberkholz@> Halcy0n: motivation is that when our devs get klined, it's
+ really hard for them to work with others on irc
+20:28 < dberkholz@> antarus: as i was saying earlier, freenode is a tool for
+ us. if that tool is getting in our way, it needs to change
+20:29 < Cardoe > dberkholz: the question is the tool getting in our way or
+ hindering us. Or will devising our own tool hinder us more..
+20:30 < Halcy0n@> Cardoe: I think us having to maintain it will be more of a
+ headache.
+20:30 < Cardoe > Halcy0n: I'm in agreement with you on that.
+20:30 <dertobi123@> dito
+20:31 < jokey@> indeed, let's discuss this there
+20:32 < Cardoe > We have other things to use manpower on, like developing a
+ distribution.
+We currently have 2 freenode group contacts: fmccor and rane.
+\agendaitem{Favor alias in docs, etc}
+I want Council to consider creating and using alias
+instead of in our docs, news items and so on. The alias
+would allow us to move out of the network more easily should we ever
+decide to do so.
+spb brought up a good point to think about.
+20:35 < spb > as people connect to and assume that
+ generic-sounding channel names are all about gentoo
+20:35 <Betelgeuse@> spb: And people connect to freenode and assume gentoo-java
+ is about generic Java
+20:37 < jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
+20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the
+ warnings all over the place.
+\agendaitem{Banning fired developers}
+\index{enforced retirement}\index{irc!ban}
+It really baffles me that some developers are forcefully retired for
+anti-social behavior, but are not consequently banned from the places
+where they display this behavior, such as our MLs and IRC channels. What
+good is it to retire developers, but allow them to continue to be
+disruptive? I would like the Council to decide for a change in our
+policy on this point.
+20:44 <dleverton_ > As I said on the list (maybe too late for anyone to have
+ noticed), since yngwin said there were're actually any devs
+ that this applies to, is there anything to discuss?
+20:45 < dberkholz@> dleverton_: i must've interpreted his response differently
+ from you
+20:45 < yngwin > i didnt say it like that, dleverton_
+20:45 < dberkholz@> what i understood was that we should ban them from the same
+ communication channel
+20:46 < dberkholz@> and allow other ones where they handled themselves
+ differently
+spb commented that the three fired devs were actually banned from
+\#gentoo-dev for quite some time.
+20:51 < musikc > from a devrel perspective, we do not give voice to every
+ dev who is retired so why should a forcibly retired dev be
+ any different?
+20:51 < tomaw > Is the council interested in the autodevoice feature or is
+ this rambling off topic?
+20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something
+ that interests us
+20:52 < Cardoe+> Standardize a policy for what happens to voluntarily
+ retired devs and forcibly retired devs.
+20:53 < Cardoe+> Can we actually tweak it?
+20:53 < Cardoe+> the council direct devrel to come up with a proposed
+ solution/policy
+20:55 < musikc > dberkholz, your call. happy to assist by doing work or by
+ just stating current process and devrel stance :)
+\agendaitem{PMS as a draft standard of EAPI 0}
+It should be treated as a draft standard, and any deviations from it
+found in the gentoo tree or package managers should have a bug filed
+against either the deviator or PMS to resolve the differences.
+Alternatively, what (specific) changes are required to PMS before such a
+statement can be made?
+The portage devs need to commit to it. How do conflicts get resolved?
+20:56 < dberkholz@> we were talking about this earlier today in here
+<20:57 < dberkholz@> to quickly summarize, EAPI 0 and portage need to agree.
+ there are some conflicts of opinion, and the question is
+ how do they get resolved?
+20:58 < dberkholz@> 17:24 < zmedico > dberkholz: mainly these two:
+20:58 < dberkholz@> 17:25 < zmedico > In both cases I consider something to
+ be negligible that the pms folks do not
+20:59 < Cardoe+> potentially creating a PMS editor post.
+21:00 < Cardoe+> Put it in the hands of a third party
+21:00 < Cardoe+> and if there's a conflict, let the council decide
+21:01 < musikc > dberkholz, conflict in that some feel PMS is biased?
+21:07 < spb > differences will be resolved by filing a bug, so what needs
+ to be sorted is what sort of escalation/mediation mechanism
+ there is
+We ran past the 1-hour mark, so this is pushed back to the list. It will
+be on the next agenda in 2 weeks if it's not resolved by then.