[swift-evolution] draft proposals should be easier to find

[Jay Abbott]

I don't really understand this concept of only accepting proposals for a
specific round. I saw some ideas that were suitable for future rounds of
proposals but not right now... Why aren't they captured in a better format
than the mailing list archive? If you don't want to be distracted by future
things then capture them as proposals but file them out of the way a bit so
that people can see they exist - I would have thought this would decrease
distractions from people bringing them up again.

On Wed, 28 Sep 2016 at 16:14 Robert Widmann <devteam.codafi at gmail.com>
wrote:

> There's a difference between "was once discussed here" and "had a proposal
> submitted to Github for consideration".  If many people are producing the
> same ideas for proposals that exist on GitHub that poses a more pressing
> risk.  But it is easier to search GitHub for such proposals than the list.
> For draft proposals that haven't made it yet, as long as they fall within
> the guidelines for proposals of a specific round, there's no reason you
> shouldn't be able to dig the discussion back up again and just talk about
> it.  Who knows, maybe you'll get a proposal submitted to GitHub that way
> with your name on it too - at the very least you'll learn something.  In a
> strange way, I guess, I'm saying we might not need this.  If somebody
> replies "by the by, we discussed this <here>" it's not meant to dismiss you
> as unoriginal.  You can use that old thread as a further jumping off point
> if you wish to continue discussion.
>
> tl;dr Keeping track of every idea pitched here would quickly grow...
> unmaintainable.
>
> ~Robert Widmann
>
> 2016/09/28 11:03、Jay Abbott via swift-evolution <swift-evolution at swift.org>
> のメッセージ:
>
> Hello,
>
> I had an idea and eventually discovered trawling through the archives of
> this list that quite a few other people have had the same idea and it has
> been discussed. Multiple times. This was not easy to discover, and judging
> from some of the messages I came across other people hadn't found and read
> them.
>
> I imagine this is frustrating and potentially time-consuming for the list,
> with people proposing or reopening ideas that have already been discussed,
> and it's likely frustrating for those people trying to get involved too,
> possibly discouraging them from participating further.
>
> I have some ideas about how to solve/mitigate this, not sure if they are
> any good, but I'd be interested to hear your thoughts.
>
> 1. Add a draft-proposals directory to the swift-evolution repo. People
> would still discuss it here first, then add a draft and send a PR.
>
> Pros:
> Easy to find and search; Easy to link to; Things that are suitable for
> future discussion/review would have a place to live until their time;
> Commonly proposed already have a place, but uncommon ones could live here;
> Could be categorised (perhaps in sub-directories or by renaming files to
> have a different prefix) for "not viable" "yes, write it up and move to
> proposals" "consider later" "no, never" etc.
>
> Cons:
> Would get big and might need some cleaning from time to time; More PRs to
> deal with - although a quick scan is all that would be needed;
>
> 2. Add a currently_proposed.md file. This would have a similar purpose,
> but would be 3 lines only - Title (link to mailing list archive of
> discussion), Description (one-line), Status/comment.
>
> Pros and Cons are basically the same as 1.
>
> 3. Add a separate category to the bug tracker for proposals.
>
> Pros: ?
> Cons: ?
>
> Not sure how that's currently used, or if mixing up dev and evolution
> related items is acceptable or not, so I'm not sure if this is
> viable/practical.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160928/00735ba0/attachment.html>