Neal Norwitz wrote:
> I recognize there is a big problem here. Each of us as individuals
> don't scale. So in order to get stuff done we need to be more
> distributed. This means distributing the workload (partially so we
> don't burn out). In order to do that we need to distribute the
> knowledge. That probably involves some changes.
Neil with deep insight states...
"""In order to do that we need to distribute the knowledge."""
+ 1000
I'm looking forward to a new tracker and hope it manages single projects...
(patches and bugs) better. It would be great if we could search for items
based on possibly the following conditions.
patch_complete
patch_reviewed
patch_approved
test_complete
test_reviewed
test_approved
doc_complete
doc_reviewed
doc_approved
For new features:
pep_completed
pep_reviewed
pep_approved
Finally: (after all the above applicable conditions are true)
accept_reject (python-dev (or BDFL) approval) [*]
*Note: Rejections could be done sooner if it obviously a bad idea.
In the case of bugs, the tests would probably come first in order to verify
and reproduce the specific bug.
What something like this would do is effectively distribute knowledge as
you suggest. For example someone good at writing docs could do a search
for all patches that do not have doc's or need docs reviewed and contribute
in that way. The same for someone interested in writing and reviewing tests.
It would also be easy for python core developers to get a list of items
that are completed *and* are reviewed and then go through those items that
are up for final approval on py-dev on a regular schedule. If it's
determined there still needs to be work on any one item, they can clear the
specific flags, (needs better tests, clear all test flags, with a
suggestion of action), Then when it is fixed and re-reviewed it will come
up for final approval again when the next final patch review period comes
around. (or sooner if a core developer wants to push it though.)
> I understand it's really hard to get involved. It can be frustrating
> at times. But I think the best way is to find a mentor. Find an
> existing core developer that you relate to and/or have similar
> interests with. I've been trying to do this more.
>
> So here's my offer. Anyone who is serious about becoming a Python
> core developer, but doesn't know how to get involved can mail me.
> Privately, publicly, it doesn't matter to me. I will try to mentor
> you.
Cool! Thanks.
> Be prepared! I will demand submissions are high quality which at a
> minimum means:
>
> - it adds a new test, enhances an existing test or fixes a broken test
> - it has *all* the required documentation, including
> versionadded/versionchanged
> - most people think the feature is desirable
> - the code is maintainable and formatted according to the prevailing style
> - we follow the process (which can include improving the process if
> others agree)
> ie, there's no free lunch, unless you work at Google of course :-)
>
> It also means you are willing to hold other people up to equally high standards.
I wouldn't expect less.
> Your contributions don't have to be code though. They can be doc,
> they can be PEPs, they can be the python.org website. It could even
> be helping out with Google's Summer of Code. The choice is yours.
I wonder if a tracker could also have patch requests. Similar to bugs,
except it's more of a todo list. Oh, never mind there is a feature request
group already. Could that possibly be extended to other areas?
_Ron