New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explain the "status quo wins a stalemate" principle in the devguide #57649
Comments
I've linked http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html in response to enough tracker issues and python-ideas threads now, that I'm convinced it (or at least something along those lines) belongs in the devguide. It wouldn't hurt to also include something along the lines of: |
+1 |
Or expand 'Reporting Bugs' to 'Reporting Bugs and Requesting Features', perhaps renamed to 'Suggesting Improvements'. My point is that aspiring developers are not the only one that need to read the guideline, not withstanding the fact the some new developers or would-be developers are also enthusiastic in making proposals. |
Maybe just add links to the two essays. |
I'd be willing to make a patch for this if you are agreed to just adding a couple of links to it (or otherwise). |
Would this be the appropriate place for the links to the two essays: http://docs.python.org/devguide/#proposing-changes-to-python-itself |
Better organization could help here. I could see the devguide being a combination of (1) a brief document meant to be read cover to cover that captures the minimum one needs to know (as well as describing what else is available in the guide), and (2) more detailed info that someone could read on an as-needed basis or that a core developer could link to if assisting someone on a certain point (like the point covered by this issue). Currently, the devguide is harder to soak in because there is no boundary between (1) and (2). A recent example is that I didn't know about the custom repo option until Antoine mentioned it in a comment -- even after having looked at many of the sections. On the plus side, he was able to link to it with the current organization. |
Personally, I would start out with a question in the FAQ. It could be called something like, "When is a change to Python justified?" and go after or in the same section as the question, "Where should I suggest new features and language changes?" Then it could be referenced from other sections as needed (e.g. from "Changing the Python Language," "Reviewing Patches," etc). |
I'd suggest two things: Clearly separate "Essential Reading" and "Additional Resources" headings on Add "Tips & Tricks" and "Design Philosophy" sections somewhere. |
Patch affects faq.rst/index.rst. In faq I put the two links along with some text as Chris suggested. In index I changed resources to Additional Resources and split up the old 'Resources' into 'Additional Resources/Essential Reading'. Feedback appreciated I will incorporate any new ideas into a version 2 and so forth until issue resolved. |
New changeset ec52e044421d by Nick Coghlan in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: