Re: Alternative proposal (+call for seconds): Expire 2-R members every year
On 06/12/14 at 13:26 -0800, Steve Langasek wrote: On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote: Rationale - First, I think that there is wide agreement that a more regular turn-over among TC members would be a good thing. And both Stefano's and this proposal aim at addressing this, by ensuring that at least 2 members of the TC are replaced every year. However, too much turn-over, with more than 2 replacements at one point of time, might have negative effects too. The TC might be temporarily weakened by having more young members; replacing more than two members at one point will cause less replacements later; it increases the difficulty of finding new members. The recent situation, with three TC members resigning, should not be treated as exceptional in the context of this resolution. If it were to happen again, I don't think that we should add one or two automatic expirations to the three resignations. This proposal differs from the original proposal by counting all resignations and removals as part of the desirable 2 per year replacement rate, so that the total number of replacements does not exceed two if only one or two younger members decide to resign. This version of the proposal could even result in an internal TC discussion: OK, the Project wants two members to be replaced. Are there members that feel like resigning now? Or should we just fallback to the default of expiring the two most senior members?. I think that such a discussion would be a healthy way for each TC member to evaluate its status. The orignal proposal could have the detrimental effect of pushing inactive/demotivated members to stay on the TC until their expiration, to avoid causing additional churn. The pathological corner case here appears to be that the longest-serving member of the TC could evade the term limit indefinitely. A scenario that assumes good faith on the part of all TC members is: - The longest-serving member of the TC spends a minimum amount of time engaging with TC issues. They vote on all resolutions, but don't spend much time cross-examining the petitioners, nor do they participate in resolution drafting. From their perspective, they are doing their duty on the TC, but other members of the TC have a faster response time to issues and therefore wind up doing the bulk of the work. - The other members of the TC all are very passionate about their work on the committee. (They've all been serving less than 3 years, so they have a lot of passion for it.) They engage with every issue, spend several hours each week on trying to make the TC serve the needs of the project as best they know how. And once or twice each year, there is a big issue that lands on the TC's desk, with social and technical issues intertwined and that require a lot of energy to pick apart. Once a year, one of these issues further devolves into a public flamewar where the ethics of the TC members themselves are called into question. And as a result, two members of the TC per year resign. - With the minimum turnover requirement met, the longest-serving member continues to serve as long as they are comfortable doing so. Did you consider this corner case in your analysis? If you think this corner case is less important than the risk of high turnover in the TC, could you elaborate why you think this? Your scenario describes a case where a member of the TC fullfills their voting duties, but does not otherwise really participate in TC work. This can happen, but I don't really see a correlation between this happening, and the seniority of that specific TC member. One could imagine a scenario where a recently-appointed TC member goes semi-MIA very early, and still stay on the TC for 4 years. After all, in Debian teams, people go MIA for various reasons, and this is not correlated with their seniority in those particular teams. I think that the root goal of this GR is to force more turn-over in the TC, which is a very desirable thing. Doing that by removing the most senior members every year is a reasonable default choice. However, the goal of this GR is NOT to provide a mechanism to automatically 'expire' poorly-performing TC members. I am not sure that this is necessary: we already have a mechanism to remove members of the TC (§6.2.5), which has already been used in situations where members of the TC had become inactive. I doubt that we need more than that. Also, if the version of the GR I proposed gets chosen, I hope that the fact that resignations or removals can 'save' other members from expiration will result in yearly discussions where the status and activity level of each member gets reviewed, which could actually help address the general problem of semi-MIA TC members. Lucas signature.asc Description: Digital signature
Re: Alternative proposal (+call for seconds): Expire 2-R members every year
On Sun, Dec 07, 2014 at 02:55:23PM +0100, Lucas Nussbaum wrote: Your scenario describes a case where a member of the TC fullfills their voting duties, but does not otherwise really participate in TC work. This can happen, but I don't really see a correlation between this happening, and the seniority of that specific TC member. One could imagine a scenario where a recently-appointed TC member goes semi-MIA very early, and still stay on the TC for 4 years. After all, in Debian teams, people go MIA for various reasons, and this is not correlated with their seniority in those particular teams. We don't have date for this either way, but I'd say (as gut feeling / experience in various teams) that yes: the likelihood of going MIA is very much correlated with seniority in any given team. Intuitively, that's also very easy to explain: when you join a team, you do so because you're enthusiastic about it; with time passing, boredom kicks in. After all, that's why team rotation is an encouraged practice in many large-scale organization. Also, if the version of the GR I proposed gets chosen, I hope that the fact that resignations or removals can 'save' other members from expiration will result in yearly discussions where the status and activity level of each member gets reviewed, which could actually help address the general problem of semi-MIA TC members. Discussions about under-performing fellow team members are very difficult/awkward in general, and even more so in volunteer organizations where we are all peers. This is why I'm convinced that an automatic, non-optional expiry method would actually be a plus, rather than a hindrance. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Urgent, confirmation of Debian 7.7.0 amd64 specs
Dear All My name is Quek from Malaysia. I am now downloading Debian 7.7.0 amd64. Right now my workstation uses w** 7 ultimate 64bit, with one(1) CPU (Core i7-4770K), and 32GB of RAM. Before I decide to install it for my upcoming compute-server, I need to confirm with ALL the following: 1. According to: https://www.debian.org/ports/amd64/ Debian 7.7.0 amd64 supports up to 64TB of RAM, which is much more than even the 192GB limit for w**. Kindly confirm. 2. According to: https://www.gnu.org/philosophy/ubuntu-spyware.html It appears to me that some GNU OS has this annoying problem, how about Debian 7.7.0 amd64? 3. According to: https://www.gnu.org/distros/common-distros.html It appears to me than some of the features in the firmware/repository are not free. Therefore, during installation of Debian 7.7.0 amd64, a. the installer in some cases recommends these nonfree firmware files for the peripherals on the machine. Will I be given the choice not to install those nonfree features? b. If I do so, i. Will it affect the performance of the OS? ii. Will the maximum supporting RAM remains 64TB? iii. Will I still benefit from ALL advantages amd64 offers, as described in A complete 64bit userland of site https://www.debian.org/ports/amd64/? 4. According to http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-dvd/ , There are 5 isos (which I am downloading) Debian-7.7.0-amd64-DVD-1.iso 2014-10-18 15:39 3.7G Debian-7.7.0-amd64-DVD-2.iso 2014-10-18 15:39 4.4G Debian-7.7.0-amd64-DVD-3.iso 2014-10-18 15:39 4.4G Debian-update-7.7.0-amd64-DVD-1.iso 2014-10-19 02:16 4.2G Debian-update-7.7.0-amd64-DVD-2.iso 2014-10-19 02:19 1.6G Which of them is/are mandatory for installation of Debian 7.7.0 amd64? (Note: Please do NOT direct me to the net-installer! I need a robust DVD file than enables me to install it offline! Moreover, this compute-server may not be connected to the internet) 5. Some Server OS (such as w** server standard), supports only few (e.g. less than 4) CPUs. Some others (such as w** server datacenter), supports infinite CPUs. So how about Debian 7.7.0 amd64? - Hope to hear from you soon. Regards Quek
Urgent! Questions/Confirmations concerning *Debian 7.7.0 amd64* before I install it.
Dear All My name is Quek from Malaysia. I am now downloading Debian 7.7.0 amd64. Right now my workstation uses w** 7 ultimate 64bit, with one(1) CPU (Core i7-4770K), and 32GB of RAM. I need your help! Before I decide to install it for my upcoming compute-server and possibly even my current workstation, I need to confirm with ALL the following: -- 1. According to: https://www.debian.org/ports/amd64/ It appears to me that Debian 7.7.0 amd64 supports up to 64TB of RAM, which is much more than even the 192GB limit for w**. Kindly confirm. 2. According to: https://www.gnu.org/philosophy/ubuntu-spyware.html It appears to me that some GNU OS has this annoying problem, how about Debian 7.7.0 amd64? 3. According to: https://www.gnu.org/distros/common-distros.html It appears to me than some of the features in the firmware/repository are not free. Therefore, during installation of Debian 7.7.0 amd64, a. the installer in some cases recommends these nonfree firmware files for the peripherals on the machine. Will I be given the choice not to install those nonfree features? b. If I do so, i. Will it affect the performance of the OS? ii. Will the maximum supporting RAM remains 64TB? iii. Will I still benefit from ALL advantages amd64 offers, as stated in A complete 64bit userland of site https://www.debian.org/ports/amd64/? 4. According to http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-dvd/ , There are 5 isos (which I am downloading) Debian-7.7.0-amd64-DVD-1.iso 2014-10-18 15:39 3.7G Debian-7.7.0-amd64-DVD-2.iso 2014-10-18 15:39 4.4G Debian-7.7.0-amd64-DVD-3.iso 2014-10-18 15:39 4.4G Debian-update-7.7.0-amd64-DVD-1.iso 2014-10-19 02:16 4.2G Debian-update-7.7.0-amd64-DVD-2.iso 2014-10-19 02:19 1.6G Which of them is/are mandatory for installation of Debian 7.7.0 amd64? (Note: Please do NOT direct me to the net-installer! I need a robust DVD file than enables me to install it offline! Moreover, this compute-server may not be connected to the internet) 5. Some Server OS (such as w** server standard), supports only few (e.g. less than 4) CPUs. Some others (such as w** server datacenter), supports infinite CPUs. So how about Debian 7.7.0 amd64? -- Hope to hear from you soon. Regards Quek
