summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authordistix ticketing system <distix@pieni.net>2017-12-28 12:50:06 +0000
committerdistix ticketing system <distix@pieni.net>2017-12-28 12:50:06 +0000
commit037031f039f7767075e76e05d4daf323e6319679 (patch)
tree5986d4d5ccdb7bfcf67f9f601c172048dd0e751e
parentdbea47142ad59bc445882214880a04e6af35c862 (diff)
downloadick-devel-distix-037031f039f7767075e76e05d4daf323e6319679.tar.gz
imported mails
-rw-r--r--tickets/84022c943cd848fd9ec630b8979dab3d/Maildir/new/1514465406.M12296P28290Q1.koom261
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">&gt; I&#39;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 &quot;A-ha&quot; 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 &quot;try&quot; new ways =
+of working, so the voted item might be re-discussed, re-voted, and changed =
+in future sprints, unless the &quot;trial&quot; was successful.=C2=A0</div>=
+<div><br></div><div><span class=3D"gmail-im"><div>&gt; Hierachical power st=
+ructures are simple. Democracy tends to be messy.</div><div><br></div></spa=
+n><div>Completely agree. An yet it&#39;s interesting to think where clear o=
+wnership is beneficial. For example, Scrum is trying to combine democracy a=
+nd hierarchical ownership for &quot;the best from both Worlds&quot;.</div><=
+div><br></div><div>I&#39;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 &quot;What and Why&quot;, 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 &quot;How&quot; 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">&lt;<a href=3D"mailto:liw@liw.fi" target=3D"_blank">=
+liw@liw.fi</a>&gt;</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>
+&gt; Without much prior Open Source governing experience, I would say<br>
+&gt; that the text is spot on: Easy to understand, fair, and intelligent.<b=
+r>
+<br>
+</span>Thanks.<br>
+<span class=3D""><br>
+&gt; The levels of agreement (mundane decisions, group discussion, and<br>
+&gt; voting) are especially interesting and useful also to my own Agile<br>
+&gt; coaching and training workshops. :)<br>
+<br>
+</span>I&#39;d be interested in hearing more about this.<br>
+<span class=3D""><br>
+&gt; I=E2=80=99m curious, did / does Linux development have similar<br>
+&gt; 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&#39;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&#39;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 &quot;benevolent dictator&quot; (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&#39;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--