I'm seeing a lot of good pitches (at least ideas in early stage, before a proper proposal) that generate a lot of interest and discussion on their threads but eventually the conversation dies down, or they get buried by other more recent / frequently commented threads.
What happens to those? How do we make sure they don't get forgotten? One could assume that if we forgot them, maybe they weren't all that important.
One could also take the opinion that that's the purpose of the proposals - they get scheduled to have their fair time to be evaluated. And if no one picked it up to turn into a proposal, maybe it wasn't successful enough of a pitch.
But sometimes, the way the thread discussion headed, they just sort of reach a place where there was not much else to follow up with that is useful to discuss, and the person pitching may not be comfortable enough / familiar enough / or have enough time to draft a proper proposal.
I'm wondering if there is, or if there should be be a something we could do about these pitches. It seems most people avoid meaningless "bump" posts anyway (rightly so in my opinion), so the thread eventually gets buried.
So what do you folks think, should there be a way to make sure older pitches don't get forgotten?
The big hurdle to go from pitch to proposal since Swift 3 is implementation. You can’t make it to review without an implementation anymore. Pitches serve the role of having an initial discussion and guaging community interest as well as identifying potential collaborators.
Pitches also capture the idea for the community even when nobody is ready to work on an implementation yet. I think there have been some cases where an implementer later appears and the pitch is able to move forward.
I think it would be interesting to provide a categorized list of pitches that have been generally well received by the community but don’t have an implementer yet. That would make it easier for potential implementers to find things they might like to work on and help collaborators make connections.
i’d go so far as to say this stage of the swift evolution process is fundamentally broken. it’s way too dependent on the specific person who pitched the idea in the first place, and if the person isn’t aggressive enough to drive it forward, it basically dies. if the person isn’t politically savvy enough to get the proposal to win in the review phase, it and all similar ideas get shut out forever under the whole “this has already been rejected” rationale.
i went through some of the topics I started in the past that got at least some support or generated some discussion:
though it seems like other people are starting to take up swords on this since there’s been a lot of interest in “swift numerics” recently.
One thing that seems common to a lot of these dead pitches is people like to punt the pitch to some handwavium feature X and say “well we should really wait until we have X in the language” or “this won’t be a problem once we have X” at the expense of real, concrete solutions to the immediate problem. “Variadic Generics” seems to be a common excuse i hear a lot. @compilerEvaluable is another.
Another issue i’ve noticed is a lot of people like to point out corner cases or poorly-defined semantics in parts of a pitch, but offer no potential solutions or answers. This is a great way to kill a proposal through confusion and uncertainty.
Some things I think would make a good starting point for fixing this process would include
a well defined timetable for moving pitches to proposals, and then review. right now everything moves at the pace of “whenever so-and-so feels like it”, which most often translates to “never”.
discouraging mission creep and discouraging people from trying to connect small problems that have feasable solutions to larger intractable, structural issues with the language.
making it a policy that anyone who asks a question about the semantics of a pitched feature, should propose a definition for those semantics.
create a “retry” pathway to advance good ideas that failed in review because the original proposal author lacked the political skill to get the support the proposal needed.
To be fair, we really don’t want 15 solutions to a problem that each complicate the language, if we have some idea of a holistic solution that will solve the problem in the future. If the solution can be wholly replaced later with no impact on source or ABI compatibility, that’s fine though.
I agree we do need a way to track these “wants” that have been deferred, before they hit the review phase.
Realistically, it’s the responsibility of the people proposing/agreeing with the proposal to deal with any issues the proposal brings up. It’s not fair to say “you can only criticise if you’ve got a solution to the problem” - there may not be any solution to the problem given, and if I don’t agree with the proposal and I find a flaw, should I be required to solve the problem for you? I’m not saying this to be rude, just saying the reason we discuss proposals is to sort out their merit in the first place.
Actually, it is not a bad brainstorming strategy to require anyone putting forth a complaint, to also put forth a solution. It’s a recognition of the fact that it is usually much easier to criticize than it is to create.
Oh great, so we can only criticise things that have solutions.
Bombs kill people. Should we only be able to criticise them if we can create bombs that don’t kill people? Something is seriously wrong with your logic, @taylorswift.
This isn’t what the OP is trying to address. The point there is quite well stated that many ideas seem to get forgotten with time, and the question is whether we can come up with a system so that those ideas can be retained over time.
You’re writing as though the aim is to drive proposals foward faster. Implicit is the assumption that ideas shouldn’t sit around over time. So, if some barrier has caused an idea to be deferred (for example, being blocked on a larger feature), OP’s question is how we keep the ideas nonetheless present somewhere while shelved, and yours is about how not to shelve it.
I would disagree with the assumptions that you’re making. Many of the biggest features in Swift 5 represent ideas that have been marinating for years before finally going through this process and have benefited from extensive revisions. Meanwhile, some are still found to be in need of revision because the original design turns out to have been defective in some way. With ABI stability, any future additions stay with us forever. I would argue that in some ways this process is too rushed, not too slow.
It would be nice if we could return in this thread to contemplate OP’s original prompt about how best to nurture ideas while they marinate.
+1. I think solving this in an organized way would be of great benefit to the community. Right now all we have is an archive of past forum threads. I think we could do a lot better than that.
I think something along the lines of a document indexing “possible future directions” could help to facilitate conceptual work and connect ideas to implementers. It would certainly make these ideas much more visible to the community than they are today. It would also give people a place to look before starting forum threads when they have an idea they want to discuss. Much of the time a very similar idea has already been discussed in the past.
I second this, a well organized markdown page would be enough I think. So the community can simply create a pull request to add their pitch into the list under a specific category of course. This will also help when new community members come to the forum and pitch an existing idea, then we can simply point them to that list where they can find the same pitch and accumulate their ideas to the main thread.
It would be nice to have the Swift evolution proposal database, commonly rejected changes and the proposed “future sound of Swift” document all under the swift.org umbrella (maybe evolution.swift.org?), all open to pull requests.
We should probably get an RFC tracker. A real tracker, not github issues (…). Lets track by time and state, category and syntax impact (and more?!). There is so much metadata about RFCs that would be useful if it was understandable by computers. Lay people could get a better idea of what’s going on, and contributors could see what’s happening at a glance.
Maybe we could start by agreeing on a data model of a well-received pitch, then we can build a list of those in YAML in a GitHub repo and then it’s fairly easy for someone to donate a nice viewer like the one used for proposals?
struct Pitch {
let name: String
let summary: String
let authors: [String]
let forumTopics: [URL]
let tags: [String]
}
Some problems don’t have solutions - they’re intrinsic. It’s not my problem you propose something that has an intrinsic problem, and I’ve got a right to point it out without wasting my time on something I see as pointless.
Since we already use Jira for bugreports how about also using Confluence for the rest? They have a Markdown PlugIn: Markdown for Confluence | Atlassian Marketplace and the whole suite is available for free for Open Source Communities as you can ask for a free license here: Open Source Project License Request | Atlassian On the other hand Apple should be able to afford such a license for their community. Apple anyone? @tkremenek?
I think the discussion about where to host a document and what format to use is great! However, I think the more challenging part is deciding on a process we would use to add pitched features to the document.
This document needs to be carefully curated in some way. If we end up with a list of everything that has ever been pitched it will quickly get too large to be useful. Noise will overwhelm signal. What we want is a way to do an initial vetting of ideas that don’t yet have an implementation. Formal review would be overkill, but the big question in my mind is who decides what goes into this list and how is that decision made? I don’t have a concrete suggestion but would love to see discussion around this question.
It just came to mind that the Generics Manifesto is an existing document that is similar to what we are discussion here in many respects, but focused on a specific aspect of the language. Perhaps what we need is a more robust process for the community-contributed pitches to become part of a relevant manifesto (and to introduce a new manifesto when a relevant manifesto does not exist).
Structuring well-received pitches into manifestos instead of a database could possibly lead to a more coherent story. With a system of manifestos such as “Text Processing” or “Software Architecture”, we could move from suggesting an isolated feature to finding where and how the feature fits into the bigger picture. That would be great. (In my opinion it’s one of the major weaknesses of community-driven language development that the contributors often think of the language as being a bag of mostly independent features instead of a balanced, organic system.)
To be honest, I'm not sure how I feel about this idea. Sure a manifesto of all possible features is great, but who should decide what pitch should be added or rejected and what will the bar look like for the inclusion, even if the pitch is well received. On the other hand an organized list of feature topics wouldn't have any of these issues. I personally would think that we could some like the following, where each topic is a link to the forum thread.
(this is only an example of possible bullet points - these are also no real links here, so don't bother clicking on them )
Other category
etc.
Such a GitHub web-page could be pinned in the forums so everybody can see the list of features that the community ever brought up and their state. Then you can go to that thread and catch up on its state and contribute your own ideas or provide help.
I added duplicates in the example, but I would want to avoid them on the main page if possible, so that contributes takes place at one place.
That said I would prefer a simpler solution for that problem, which works by FIFO principle. If you pitch something new as first, you can create a PR for its inclusion into the list, even if the idea is later rejected, but if not we'll have a historical reference so it can be pushed further by the community in case it gets deferred.
Since this will rely mostly on the community effort I think we would have the responsibility to scan the forums for some ideas which we liked in the past that we think should be included in the list.
To sum up in one sentence, I would wish for a community driven https://apple.github.io/swift-evolution/ page with slightly different metadata and support for multiple tags, that will accumulate pitches and possible future features or extensions to the language.
We certainly wouldn’t want a single manifesto with all possible features! I was suggesting that maybe several documents in a style similar to the generics manifesto, each with a specific focus area might be a good idea.
I think the answer to your question about inclusion is that we would benefit from having a process for doing preliminary vetting of ideas. I don’t know exactly what that would look like, but it would give us a more coherent record of discussions and ideas that have happend and have stalled pending either implementation or other prerequisite features.
Your suggestion is a nice way of organizing forum history. It certainly could be useful in some contexts to have a comprehensive index of ideas that have been discussed.
But I don’t think it would be as effective at facilitating work on pitches that have reached some preliminary buy-in from the community. For that purpose I think we really need a more cohesive “design direction” document(s) that require some preliminary vetting for inclusion. Included features would have broad support and be likely to receive consideration / review in the future when an implementation arrives. This is a much higher bar than “someone decided to post a pitch at sometime in the past”. The higher bar would filter out a lot of noise.
)