diff options
author | distix ticketing system <distix@pieni.net> | 2017-12-28 12:50:06 +0000 |
---|---|---|
committer | distix ticketing system <distix@pieni.net> | 2017-12-28 12:50:06 +0000 |
commit | 037031f039f7767075e76e05d4daf323e6319679 (patch) | |
tree | 5986d4d5ccdb7bfcf67f9f601c172048dd0e751e | |
parent | dbea47142ad59bc445882214880a04e6af35c862 (diff) | |
download | ick-devel-distix-037031f039f7767075e76e05d4daf323e6319679.tar.gz |
imported mails
-rw-r--r-- | tickets/84022c943cd848fd9ec630b8979dab3d/Maildir/new/1514465406.M12296P28290Q1.koom | 261 |
1 files changed, 261 insertions, 0 deletions
diff --git a/tickets/84022c943cd848fd9ec630b8979dab3d/Maildir/new/1514465406.M12296P28290Q1.koom b/tickets/84022c943cd848fd9ec630b8979dab3d/Maildir/new/1514465406.M12296P28290Q1.koom new file mode 100644 index 0000000..56947e2 --- /dev/null +++ b/tickets/84022c943cd848fd9ec630b8979dab3d/Maildir/new/1514465406.M12296P28290Q1.koom @@ -0,0 +1,261 @@ +Return-Path: <lare.lekman@gmail.com> +X-Original-To: ick-devel@liw.fi +Delivered-To: distix@pieni.net +Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) + by pieni.net (Postfix) with ESMTPS id 8976941406; + Thu, 28 Dec 2017 10:15:56 +0000 (UTC) +Received: by mail-it0-x236.google.com with SMTP id p139so27771548itb.1; + Thu, 28 Dec 2017 02:15:56 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc; + bh=5El5qGUIC2zLrbqB2cIr+HE053KDyyO8yGmJJSro2sE=; + b=FlA+LWHQ08vKvJYLWgYTBRDP9lEVc/09CnIjjqvqkO/hEWPNmQGG8eyi8/kVehTaQC + 0FsXfwG86K4EjGSPw0YPzlXJcIkIjaW4WqDC3Z0usF0ZFsKLe8IL9/+sPM3uTHscneBX + UMXStDSkh9Rym4kKXyl6awzE8AacEwIQox3Iaq6DvRosMhjs8mJFbPA0Qgh4lBmysZ5A + fyKKQoBmmOtxBmS9tsu56PxUjAUhHsnrJVDiotqkg2WDspXwHw0sH8SSecErWIkfLs3W + ltrfY/NekGtUF4tHQnOcBjTmB4rfeKDYbL5S3UlSjq6M/vZ9O2dNrvPZnmGxDtb4zeOY + 99SA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to:cc; + bh=5El5qGUIC2zLrbqB2cIr+HE053KDyyO8yGmJJSro2sE=; + b=ar3SzpPLjOWyZVOPt50ddNOX7fpdxIAHjT/CrsTm0oIa3j6DlvcgAi2mJJU6jA0fm/ + C+ILTdZq6+W7COlK19kdkc5Rs1/a5Tyk6jma/oyx5wDJZz8TjEqtvOX+rh497qlH2T0E + WEluICMw69Wn6/E5cC1YXn2lHD0HEFs5CDZPhU7HbzG2EFCoUOL1E9PVuJZVzxY1Gc2o + 4L+sHmY0F7SC7rPfBzttqNvrsbrYxk7D29XWEMgp7P4iAgZhxDRj6FD0j86PiOm7Fe9a + sI4j2LZyvqqglHSGs6uVRMt6P0JxC4JRz+SaXb5dvNM9I6RyqwAOXqfNHbZhLc+bVJqF + qB/w== +X-Gm-Message-State: AKGB3mIDcwPgAOkfXV4RRUI30tBevU3ci4sCeBfeUf1lY3ctE1DT/+Jg + JyH3uoeye8PiVmI8qpMWvrP+JHFhPpEkTdrPGTS0Ww== +X-Google-Smtp-Source: ACJfBotDq+GzM6NByHkIl5n62YiyQcNFWULNGLO7Dh66gOcGEiHZS3w58oBTuTjuYSvYwDBucsSCtdQgpHvIOr0Nmr4= +X-Received: by 10.36.64.141 with SMTP id n135mr38800836ita.122.1514456155087; + Thu, 28 Dec 2017 02:15:55 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.107.200.18 with HTTP; Thu, 28 Dec 2017 02:15:54 -0800 (PST) +In-Reply-To: <20171224080932.vz2jmalag47e7vtu@exolobe3> +References: <20171220213303.drdmrnpscvoaz4l7@exolobe3> <105C7298-D800-44A6-82E6-1F7AA2088570@gmail.com> + <20171224080932.vz2jmalag47e7vtu@exolobe3> +From: Lare Lekman <lare.lekman@gmail.com> +Date: Thu, 28 Dec 2017 12:15:54 +0200 +Message-ID: <CAHzxMHMC4SBH_wG=8a4OaD_AS4o9X_u0ov6x5bPXJ06ydzP4Gw@mail.gmail.com> +Subject: Re: On project governance +To: Lars Wirzenius <liw@liw.fi> +Cc: Ick develoment <ick-devel@liw.fi> +Content-Type: multipart/alternative; boundary="001a1143a44026e78c056163cd44" + +--001a1143a44026e78c056163cd44 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thank you Lars. + +> I'd be interested in hearing more about this. + +Ok. For my Agile coaching sessions (where participants figure out how to +make their work more enjoyable and efficient), the levels of agreement +(from Ick) could be a nice reminder about the decision process: + +1) Mundane decisions. These may be simple personal "A-ha" moments, small +agreements, or changed thinking of each participant. I usually ask these +thoughts, one by one, in the end of my workshops. +2) Group discussion. This is where most of the workshop takes place, +however the facilitation technique also matters, including the recording +style for group decisions (usually flip charts and post-its are used). +3) Voting. When the group cannot agree (within a reasonable time), the +facilitator (such as a Scrum Master) should propose a vote. The idea in +Agile development is to "try" new ways of working, so the voted item might +be re-discussed, re-voted, and changed in future sprints, unless the +"trial" was successful. + +> Hierachical power structures are simple. Democracy tends to be messy. + +Completely agree. An yet it's interesting to think where clear ownership is +beneficial. For example, Scrum is trying to combine democracy and +hierarchical ownership for "the best from both Worlds". + +I'm not sure if we should consider using some or all of the Scrum roles +with Ick. However, the idea in Scrum is that the Product Owner has the +final say on the "What and Why", i.e. order and content of the Product +Backlog Items (such as user requirements, user stories, features, +improvements, and bug fixes), to represent the user needs. Then, the +Development Team can decide on "How" the requirements are designed and +developed (according to the common architecture and other guidelines). +Finally, the Scrum Master has the ownership of the development process. All +decisions should still be as democratic as possible. + +Hopefully this helps. +Lare + +Agile Trainer & Coach | *http://lekman.fi <http://lekman.fi/>* | +358 40 +849 5117 + +On Sun, Dec 24, 2017 at 10:09 AM, Lars Wirzenius <liw@liw.fi> wrote: + +> On Sat, Dec 23, 2017 at 09:20:48PM +0200, Lare Lekman wrote: +> > Without much prior Open Source governing experience, I would say +> > that the text is spot on: Easy to understand, fair, and intelligent. +> +> Thanks. +> +> > The levels of agreement (mundane decisions, group discussion, and +> > voting) are especially interesting and useful also to my own Agile +> > coaching and training workshops. :) +> +> I'd be interested in hearing more about this. +> +> > I=E2=80=99m curious, did / does Linux development have similar +> > decision-making philosophy and levels of agreement? +> +> To the best of my understanding, Linux the kernel has nothing like +> this at all. It has always been a project where Linus has final say on +> everything. He has delegated responsibility for specific subsystems or +> other areas to specific people, but there is no voting and no hint of +> democracy, it's a completely hierarchical top-down system, except that +> people get to do what they want unless they do something someone else +> objects. The objection can come from anyone, not necessarily from +> upward in the hierarchy. +> +> The Debian project, however, has a more formal, voting based +> structure. Debian has a constitueion[1], a social contract[2], and a +> code of conduct[3], as well as a technical policy[4]. The constitution +> defines how decisions are made, and my proposed rules are inspired by +> that. Debian is quite a large project, however, and needs more +> complicated rules than Ick does. +> +> Debian also has a project leader role, which is something I'd like to +> avoid for Ick. +> +> Various other projects have variations of these structures. A lot of +> projects have some kind of "benevolent dictator" (like Linus), often +> the instigator of the project. Any power transitions tend to be by a +> feudal style where those in power name their heirs. Fairly few +> projects use voting to make project decisions. +> +> Hierachical power structures are simple. Democracy tends to be messy. +> It's a value decision. +> +> [1]: https://www.debian.org/devel/constitution +> [2]: https://www.debian.org/social_contract +> [3]: https://www.debian.org/code_of_conduct +> [4]: https://www.debian.org/doc/debian-policy/ +> +> -- +> I want to build worthwhile things that might last. --joeyh +> + +--001a1143a44026e78c056163cd44 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><span style=3D"font-size:12.8px">Thank you Lars.</span><di= +v style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px"><spa= +n class=3D"gmail-im">> I'd be interested in hearing more about this.= +<br><div><br></div></span><div><div>Ok. For my Agile coaching sessions (whe= +re participants figure out how to make their work more enjoyable and effici= +ent), the levels of agreement (from Ick) could be a nice reminder about the= + decision process:</div><div><br></div><div>1) Mundane decisions. These may= + be simple personal "A-ha" moments, small agreements, or changed = +thinking of each participant. I usually ask these thoughts, one by one, in = +the end of my workshops.</div><div>2) Group discussion. This is where most = +of the workshop takes place, however the facilitation technique also matter= +s, including the recording style for group decisions (usually flip charts a= +nd post-its are used).</div><div>3) Voting. When the group cannot agree (wi= +thin a reasonable time), the facilitator (such as a Scrum Master) should pr= +opose a vote. The idea in Agile development is to "try" new ways = +of working, so the voted item might be re-discussed, re-voted, and changed = +in future sprints, unless the "trial" was successful.=C2=A0</div>= +<div><br></div><div><span class=3D"gmail-im"><div>> Hierachical power st= +ructures are simple. Democracy tends to be messy.</div><div><br></div></spa= +n><div>Completely agree. An yet it's interesting to think where clear o= +wnership is beneficial. For example, Scrum is trying to combine democracy a= +nd hierarchical ownership for "the best from both Worlds".</div><= +div><br></div><div>I'm not sure if we should consider using some or all= + of the Scrum roles with Ick. However, the idea in Scrum is that the Produc= +t Owner has the final say on the "What and Why", i.e. order and c= +ontent of the Product Backlog Items (such as user requirements, user storie= +s, features, improvements, and bug fixes), to represent the user needs. The= +n, the Development Team can decide on "How" the requirements are = +designed and developed (according to the common architecture and other guid= +elines). Finally, the Scrum Master has the ownership of the development pro= +cess. All decisions should still be as democratic as possible.<br></div></d= +iv><div><br></div><div>Hopefully this helps.</div></div></div><div class=3D= +"gmail_extra">Lare</div><div class=3D"gmail_extra"><br clear=3D"all"><div><= +div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir= +=3D"ltr"><span style=3D"border-collapse:collapse;font-family:arial,sans-ser= +if;font-size:13px"><div><div style=3D"font-family:arial;font-size:small"><s= +pan style=3D"font-family:arial,sans-serif;font-size:13px">Agile Trainer &am= +p; Coach |</span><span style=3D"font-family:arial,sans-serif;font-size:13px= +">=C2=A0</span><u style=3D"font-family:arial,sans-serif;font-size:13px"><a = +href=3D"http://lekman.fi/" style=3D"color:rgb(17,85,204)" target=3D"_blank"= +>http://lekman.fi</a></u>=C2=A0|=C2=A0<span style=3D"font-family:arial,sans= +-serif;font-size:13px">+358 40 849 5117</span></div></div><div><div></div><= +/div></span></div></div></div> +<br><div class=3D"gmail_quote">On Sun, Dec 24, 2017 at 10:09 AM, Lars Wirze= +nius <span dir=3D"ltr"><<a href=3D"mailto:liw@liw.fi" target=3D"_blank">= +liw@liw.fi</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= +=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl= +ass=3D"">On Sat, Dec 23, 2017 at 09:20:48PM +0200, Lare Lekman wrote:<br> +> Without much prior Open Source governing experience, I would say<br> +> that the text is spot on: Easy to understand, fair, and intelligent.<b= +r> +<br> +</span>Thanks.<br> +<span class=3D""><br> +> The levels of agreement (mundane decisions, group discussion, and<br> +> voting) are especially interesting and useful also to my own Agile<br> +> coaching and training workshops. :)<br> +<br> +</span>I'd be interested in hearing more about this.<br> +<span class=3D""><br> +> I=E2=80=99m curious, did / does Linux development have similar<br> +> decision-making philosophy and levels of agreement?<br> +<br> +</span>To the best of my understanding, Linux the kernel has nothing like<b= +r> +this at all. It has always been a project where Linus has final say on<br> +everything. He has delegated responsibility for specific subsystems or<br> +other areas to specific people, but there is no voting and no hint of<br> +democracy, it's a completely hierarchical top-down system, except that<= +br> +people get to do what they want unless they do something someone else<br> +objects. The objection can come from anyone, not necessarily from<br> +upward in the hierarchy.<br> +<br> +The Debian project, however, has a more formal, voting based<br> +structure. Debian has a constitueion[1], a social contract[2], and a<br> +code of conduct[3], as well as a technical policy[4]. The constitution<br> +defines how decisions are made, and my proposed rules are inspired by<br> +that. Debian is quite a large project, however, and needs more<br> +complicated rules than Ick does.<br> +<br> +Debian also has a project leader role, which is something I'd like to<b= +r> +avoid for Ick.<br> +<br> +Various other projects have variations of these structures. A lot of<br> +projects have some kind of "benevolent dictator" (like Linus), of= +ten<br> +the instigator of the project. Any power transitions tend to be by a<br> +feudal style where those in power name their heirs. Fairly few<br> +projects use voting to make project decisions.<br> +<br> +Hierachical power structures are simple. Democracy tends to be messy.<br> +It's a value decision.<br> +<br> +[1]: <a href=3D"https://www.debian.org/devel/constitution" rel=3D"noreferre= +r" target=3D"_blank">https://www.debian.org/devel/<wbr>constitution</a><br> +[2]: <a href=3D"https://www.debian.org/social_contract" rel=3D"noreferrer" = +target=3D"_blank">https://www.debian.org/social_<wbr>contract</a><br> +[3]: <a href=3D"https://www.debian.org/code_of_conduct" rel=3D"noreferrer" = +target=3D"_blank">https://www.debian.org/code_<wbr>of_conduct</a><br> +[4]: <a href=3D"https://www.debian.org/doc/debian-policy/" rel=3D"noreferre= +r" target=3D"_blank">https://www.debian.org/doc/<wbr>debian-policy/</a><br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +--<br> +I want to build worthwhile things that might last. --joeyh<br> +</div></div></blockquote></div><br></div></div> + +--001a1143a44026e78c056163cd44-- |