The advice to avoid idioms that may not be universally understood is good.
My further issue with the misuse of "straw-man" (which really is not, or
should not be, separable from "straw-man argument") is that a "straw-man"
in the established usage is something that is always intended to be a
failure
Well, it's more of a reference to the fallacy than anything. Writing down a
proposed action implicitly claims it's what others are arguing for. It's
self-deprecating to call it a "straw man", suggesting that it may not at
all be what others are arguing for, and is done to openly invite criticism
an
Alright, that does it! Who is responsible for this "straw-man" abuse
that is becoming too commonplace in the Spark community? "Straw-man" does
not mean something like "trial balloon" or "run it up the flagpole and see
if anyone salutes", and I would really appreciate it if Spark developers
would
BTW I wrote up a straw-man proposal for migrating the wiki content:
https://issues.apache.org/jira/browse/SPARK-18073
On Tue, Oct 18, 2016 at 12:25 PM Holden Karau wrote:
> Right now the wiki isn't particularly accessible to updates by external
> contributors. We've already got a contributing t
Great idea! If the developer docs are in github, then new contributors who
find errors or omissions can update the docs as an introduction to the PR
process.
Fred
On Wed, Oct 19, 2016 at 5:46 PM, Reynold Xin wrote:
> For the contributing guide I think it makes more sense to put it in
> apache/s
For the contributing guide I think it makes more sense to put it in
apache/spark github, since that's where contributors start. I'd also link
to it from the website ...
On Tue, Oct 18, 2016 at 10:03 AM, Shivaram Venkataraman <
shiva...@eecs.berkeley.edu> wrote:
> +1 - Given that our website is n
+1 if the docs can be exposed more.
On 19 Oct 2016 2:04 a.m., "Shivaram Venkataraman" <
shiva...@eecs.berkeley.edu> wrote:
> +1 - Given that our website is now on github
> (https://github.com/apache/spark-website), I think we can move most of
> our wiki into the main website. That way we'll only
+1 - Given that our website is now on github
(https://github.com/apache/spark-website), I think we can move most of
our wiki into the main website. That way we'll only have two sources
of documentation to maintain: A release specific one in the main repo
and the website which is more long lived.
T
Is there any way to tie wiki accounts with JIRA accounts? I found it weird that
they're not tied at the ASF.
Otherwise, moving this into the docs might make sense.
Matei
> On Oct 18, 2016, at 6:19 AM, Cody Koeninger wrote:
>
> +1 to putting docs in one clear place.
>
> On Oct 18, 2016 6:40 A
+1 to putting docs in one clear place.
On Oct 18, 2016 6:40 AM, "Sean Owen" wrote:
> I'm OK with that. The upside to the wiki is that it can be edited directly
> outside of a release cycle. However, in practice I find that the wiki is
> rarely changed. To me it also serves as a place for informa
I'm OK with that. The upside to the wiki is that it can be edited directly
outside of a release cycle. However, in practice I find that the wiki is
rarely changed. To me it also serves as a place for information that isn't
exactly project documentation like "powered by" listings.
In a way I'd like
Right now the wiki isn't particularly accessible to updates by external
contributors. We've already got a contributing to spark page which just
links to the wiki - how about if we just move the wiki contents over? This
way contributors can contribute to our documentation about how to
contribute pro
12 matches
Mail list logo
