this would be true if all the time it takes for a pitch to reach maturity was actually spent refining the design and goals, but this isn’t true at all. most pitches go through long periods of time where they simply get lost at sea and forgotten until they wash ashore some months later. some, like the namespaces pitch (which i think everyone believes is sorely needed) never do get found at all. the @compilerevaluable pitch has been effectively dead since last year.
no revision is taking place while the pitch is lost at sea. no problems are being solved, and no designs are being improved, because the idea in its entirety has fallen through the cracks. to use the recently-ressurected character literals proposal as an example, it has not changed significantly in design since first proposed, and out of the year it has taken to reach review, perhaps only three weeks of that was actually spent actively working on the feature.
you’re acting like the evolution process shouldn’t be made more focused and timely because the time currently being spent is being well-spent, but it’s not. the vast majority of the time is being wasted because of disorganization and lack of direction.
Work continues apace at refining Swift PM, which directly informs the future design of namespaces and submodules. The plumbing for @compilerEvaluable is being added to the master branch as we speak. And in the intervening time much has changed about the design of String, which has a direct bearing on how we work with characters.
In each of these cases, the eventual design of these features will benefit from maturation of the language in related ways. There is nothing wrong with an idea viewed favorably being on hold in such circumstances—it’s a feature, not a bug.
There might be some older pitches (from the mailing list) in the wrong category, but they can be moved and tagged by anyone with the "regular" trust level.
I understand but I don't like that because as you already said it can be edited by a lot of people. And withdrawn tag is the one I started actually, also the off-topic one. It will be less organized then a layed out page you can contribute to. We could have a giant thread where people can notify the community through the forums of their PR so we can review it and suggest improvements. That's basically my idea but it doesn't mean that we'll end up there. Let's see where this thread will lead us.
Anything with a lot of overhead and process associated isn't going to be kept up to date. Perhaps this could be viewed similarly to “starter bugs”, and a list of “starter proposals” could be kept somewhere for cases where there's a thread with interest and something close to consensus. Then someone could write/clean up a proposal, provide the missing implementation, handle the official submission, etc.
That's not necessarily true. It depends on what the process is. We don't have trouble keeping the index of reviewed proposals up to date and anything we do for "well received but on hold" pitches / proposals would be much lighter weight than that.
The advantage of having a process is that it will increase the signal to noise ratio and it would ensure the appropriate index / list / document is updated when new ideas complete this preliminary, lightweight process. It would also provide a clear point for community members who don't follow every thread to chime in before a pitch makes it onto this list.
I'm just spitballing here, but if we used the manifesto format, we could identify a small group of "manifesto owners" for each area of the language. Perhaps a pitch that is well supported could make a "request for inclusion" into the manifesto. When that happens there would be a small time window for further comment and then the manifesto owners could make a decision on whether the feature warrants inclusion. This would be much less formal than the proposal review process, but would still have some structure with a clear decision point and rationale for the decision that is reached.
That is the main issue I see with this approach. How can we find someone that is guaranteed to know where Swift should head in the future for a specific language area, instead of being opinionated and rejecting ideas because of personal preferences.
I still strongly think that whatever the solution would be, it should avoid taking preferences into account, but rather allow everything to be included if it follows certain format guidelines. Then when the idea was fully evaluated it can be appropriately marked (e.g. with a rejected tag) to signal its (dis-) approval. Other tags can also provide more hints at which point it makes sense to push an older idea again, etc.
The solution I have in my mind would operate like this:
filter by guidelines (format / duplicates / etc)
include as part of a bigger category
create new idea entry or update existing one
present a rendered page
This would provide a well organized historical index of features that the community wants, where we can cherry pick the features that truly mimics Swifts future and close other requests by also providing some rationales for the decision.
Well this is of course subjective, just as the core team makes subjective decisions on behalf of the community at the final review stage. I would imagine the people who would "own" the manifesto would be people who have made significant contributions to the implementation of that part of the language.
How would this process handle a controversial pitch that has lots of support but also nontrivial opposition (i.e. something like Result in many of the earlier discussions about it.)? How would it handle pitches that have light participation, but mostly positive? How would it handle pitches that have support but are not actually technically viable? How would it handle overlapping ideas competing in the same feature space?
Maybe it's workable, I'm just trying to understand how we keep signal-to-noise high and provide some kind of coherent organization of the ideas so they are easily navigable / digestible.
I personally would happily accept the simplest solution and include all pitches. Again, they must follow some pre-defined guidelines such as requirement like formatting and short description (instead of being possibly too technical and specific like it can be in a manifesto if we'd compare them). We will need to filter them and categorize everything of course, that would be a responsibility of the PR reviewers. Mistakes made in that area can easily be fixed since it would only require someone to open a PR and fix tags, description, category, topic. Topics like Result don't harm anybody if they are included in such an index. More over it will show the community that there are people that do support such features and if such features are pushed hard enough, they can even change the decision from the core-team (Result initially was rejected by the core-team). Pitches that share support from the community but are not technically viable should definitely be recorded as they can be re-evaluated at later point of the language evolution when there is more band-width available.
IMO a manifesto like document on the other hand would just hit the hand-break in that area and prevent us accumulating ideas which the community could view at one place and shape to a diamond as part of the language.
Speaking differently, we have to come up with requirement for a Feature protocol:
public protocol Feature: Hashable {
associatedtype Guideline
var tags: SortedSet<Tag> { get }
var title: String { get }
var description: String { get }
var threads: [URL] { get }
...
var decisionRationale: String? { get }
}
I don’t think this is a good idea. We see more than a few well-intentioned but ill-conceived pitches on these forums. I myself am guilty of a few of these. I don’t see any value in tracking them. They would just add noise.
The Result example is one where I do think it warrants inclusion even though the matter was unsettled and quite a few people argued that it did not belong in the standard library.
I’m not sure what the best way to draw the line is. Perhaps what we need is some kind of measure of “well conceived”, “technically viable”, and “has community support” (even if there is also some resistance).
What we don’t want is to see a lot of people adding idiosyncratic pet features that don’t have much support beyond the author.
Me too, but this does not stop me from creating new pitches regardless the (missing) knowledge about the technical aspects of the feature I imagine in my mind.
I don't view this as 'tracking' but rather as a 'record' which then can be tagged as withdrawn/rejected/impossible/whatever and conveniently folded in the rendered document so it's not as noisy as I think you see it.
That mindset I obviously second, but I cannot provide an answer to that issue. The solution here must be community driven.
I don't think it should stop anyone from creating pitches. I just don't see the community benefiting in any way from having them in an index or otherwise calling any attention to them. How do we benefit from that?
Sure, because it is updated automatically as part of the heavyweight and “mission critical” proposal process, and it is also largely maintained by paid members of the Swift development team. I don't personally see much hope for success on that scale here, especially because it's going to be very hard to beat “searching the forums” (always complete and up-to-date) in terms of effort to reward ratio. That's why I would suggest either a tag (like starter bugs) or a very lightweight list somewhere.
The main reason I see to maintain such a list is to help someone looking for a small and uncontroversial proposal to drive. Anyone trying to tackle something larger (e.g. compile-time evaluation), or more controversial (e.g. Result) will likely be personally invested in adding that feature, so I doubt they would need such a list at all. They can just search the forums for past discussions.
Just out of curiosity, what would be the criteria for a "well received pitch"? I would think something around the following:
It has more than 10 comments. This indicates that people are interested enough in the topic to either argue with it or support it
The majority of the comments show support for the pitch
All the comments showing support provide clear rationale behind their decision to support the pitch
I'm sure a simple php script can sort out all the ones where there are less then 10 comments, but a human reviewer would have to consider (2) and (3) on the filtered pitches.
I like the suggestions brought up that surface or track the pitch information without much manual process (like the script with a simple heuristic).
Something automated like that would be far from perfect, but it’s nice that it doesn’t impose too much additional work on the community / core team and still help remind in some way that the ideas in those pitch threads.