Where to post a long monologue for feedback?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Where to post a long monologue for feedback?

Tim Holy
Hi all,

I have a "julep" (julia enhancement proposal) nearly ready, and it's long.
About 85% of it essentially presents "the problem" and it's written so as to
attempt to catch people up who may not have been following every last
discussion on GitHub. (This adds considerably to its length.) The rest is a
proposal for a possible solution, which I am certain will be modified by
feedback from the community.

On http://julialang.org/community/standards/, under the "Be concise" request I
notice that it says "Consider writing a blog post if you feel that you have
enough to say on a particular subject." I am therefore contemplating
submitting the "background" (the first 85%) as a blog post, and the proposed
solution as a GitHub issue. Alternatives seem to be submitting the whole thing
as a blog post, or submitting the whole thing as a GitHub issue. On balance, I
find myself liking the "split" approach best because (1) many core contributors
won't need to read the long background section to be able to intelligently
comment on the proposed solution, and (2) GitHub is where most design
decisions are made.

Does this seem reasonable? Does anyone have a better idea?

Best,
--Tim

Reply | Threaded
Open this post in threaded view
|

Re: Where to post a long monologue for feedback?

Jeffrey Sarnoff
reasonable

On Sunday, March 27, 2016 at 7:28:35 PM UTC-4, Tim Holy wrote:
Hi all,

I have a "julep" (julia enhancement proposal) nearly ready, and it's long.
About 85% of it essentially presents "the problem" and it's written so as to
attempt to catch people up who may not have been following every last
discussion on GitHub. (This adds considerably to its length.) The rest is a
proposal for a possible solution, which I am certain will be modified by
feedback from the community.

On <a href="http://julialang.org/community/standards/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\75http%3A%2F%2Fjulialang.org%2Fcommunity%2Fstandards%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHSqtp51jwVonfGnaCWab5FJT2YoQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\75http%3A%2F%2Fjulialang.org%2Fcommunity%2Fstandards%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHSqtp51jwVonfGnaCWab5FJT2YoQ&#39;;return true;">http://julialang.org/community/standards/, under the "Be concise" request I
notice that it says "Consider writing a blog post if you feel that you have
enough to say on a particular subject." I am therefore contemplating
submitting the "background" (the first 85%) as a blog post, and the proposed
solution as a GitHub issue. Alternatives seem to be submitting the whole thing
as a blog post, or submitting the whole thing as a GitHub issue. On balance, I
find myself liking the "split" approach best because (1) many core contributors
won't need to read the long background section to be able to intelligently
comment on the proposed solution, and (2) GitHub is where most design
decisions are made.

Does this seem reasonable? Does anyone have a better idea?

Best,
--Tim

Reply | Threaded
Open this post in threaded view
|

Re: Where to post a long monologue for feedback?

Elliot Saba
I agree, sounds pretty reasonable.  I always enjoy blog posts about Julia in any case, so I vote for the split approach.
-E

On Sun, Mar 27, 2016 at 9:20 PM, Jeffrey Sarnoff <[hidden email]> wrote:
reasonable


On Sunday, March 27, 2016 at 7:28:35 PM UTC-4, Tim Holy wrote:
Hi all,

I have a "julep" (julia enhancement proposal) nearly ready, and it's long.
About 85% of it essentially presents "the problem" and it's written so as to
attempt to catch people up who may not have been following every last
discussion on GitHub. (This adds considerably to its length.) The rest is a
proposal for a possible solution, which I am certain will be modified by
feedback from the community.

On http://julialang.org/community/standards/, under the "Be concise" request I
notice that it says "Consider writing a blog post if you feel that you have
enough to say on a particular subject." I am therefore contemplating
submitting the "background" (the first 85%) as a blog post, and the proposed
solution as a GitHub issue. Alternatives seem to be submitting the whole thing
as a blog post, or submitting the whole thing as a GitHub issue. On balance, I
find myself liking the "split" approach best because (1) many core contributors
won't need to read the long background section to be able to intelligently
comment on the proposed solution, and (2) GitHub is where most design
decisions are made.

Does this seem reasonable? Does anyone have a better idea?

Best,
--Tim


Reply | Threaded
Open this post in threaded view
|

Re: Where to post a long monologue for feedback?

Stefan Karpinski
+1. The split approach sounds good to me.

On Mon, Mar 28, 2016 at 10:30 AM, Elliot Saba <[hidden email]> wrote:
I agree, sounds pretty reasonable.  I always enjoy blog posts about Julia in any case, so I vote for the split approach.
-E

On Sun, Mar 27, 2016 at 9:20 PM, Jeffrey Sarnoff <[hidden email]> wrote:
reasonable


On Sunday, March 27, 2016 at 7:28:35 PM UTC-4, Tim Holy wrote:
Hi all,

I have a "julep" (julia enhancement proposal) nearly ready, and it's long.
About 85% of it essentially presents "the problem" and it's written so as to
attempt to catch people up who may not have been following every last
discussion on GitHub. (This adds considerably to its length.) The rest is a
proposal for a possible solution, which I am certain will be modified by
feedback from the community.

On http://julialang.org/community/standards/, under the "Be concise" request I
notice that it says "Consider writing a blog post if you feel that you have
enough to say on a particular subject." I am therefore contemplating
submitting the "background" (the first 85%) as a blog post, and the proposed
solution as a GitHub issue. Alternatives seem to be submitting the whole thing
as a blog post, or submitting the whole thing as a GitHub issue. On balance, I
find myself liking the "split" approach best because (1) many core contributors
won't need to read the long background section to be able to intelligently
comment on the proposed solution, and (2) GitHub is where most design
decisions are made.

Does this seem reasonable? Does anyone have a better idea?

Best,
--Tim



Reply | Threaded
Open this post in threaded view
|

Re: Where to post a long monologue for feedback?

Tim Holy
OK, draft blog post is here:
https://github.com/JuliaLang/julialang.github.com/pull/366
and GitHub issue is here:
https://github.com/JuliaLang/julia/issues/15648

If upon reading you decide this format doesn't work, just let me know.

--Tim

On Monday, March 28, 2016 10:56:36 AM Stefan Karpinski wrote:

> +1. The split approach sounds good to me.
>
> On Mon, Mar 28, 2016 at 10:30 AM, Elliot Saba <[hidden email]> wrote:
> > I agree, sounds pretty reasonable.  I always enjoy blog posts about Julia
> > in any case, so I vote for the split approach.
> > -E
> >
> > On Sun, Mar 27, 2016 at 9:20 PM, Jeffrey Sarnoff <
> >
> > [hidden email]> wrote:
> >> reasonable
> >>
> >> On Sunday, March 27, 2016 at 7:28:35 PM UTC-4, Tim Holy wrote:
> >>> Hi all,
> >>>
> >>> I have a "julep" (julia enhancement proposal) nearly ready, and it's
> >>> long.
> >>> About 85% of it essentially presents "the problem" and it's written so
> >>> as to
> >>> attempt to catch people up who may not have been following every last
> >>> discussion on GitHub. (This adds considerably to its length.) The rest
> >>> is a
> >>> proposal for a possible solution, which I am certain will be modified by
> >>> feedback from the community.
> >>>
> >>> On http://julialang.org/community/standards/, under the "Be concise"
> >>> request I
> >>> notice that it says "Consider writing a blog post if you feel that you
> >>> have
> >>> enough to say on a particular subject." I am therefore contemplating
> >>> submitting the "background" (the first 85%) as a blog post, and the
> >>> proposed
> >>> solution as a GitHub issue. Alternatives seem to be submitting the whole
> >>> thing
> >>> as a blog post, or submitting the whole thing as a GitHub issue. On
> >>> balance, I
> >>> find myself liking the "split" approach best because (1) many core
> >>> contributors
> >>> won't need to read the long background section to be able to
> >>> intelligently
> >>> comment on the proposed solution, and (2) GitHub is where most design
> >>> decisions are made.
> >>>
> >>> Does this seem reasonable? Does anyone have a better idea?
> >>>
> >>> Best,
> >>> --Tim