FWIW, there's already kind of a process described at http://code.google.com/p/pharo/wiki/HowToContribute
I do agree with you on some things which could/should be changed though:
On May 20, 2010, at 3:03 09PM, laurent laffont wrote:
> I was thinking about following rules to make life easier:
> - a submission in PharoInbox must be a slice
+1.
Makes it much easier to scan the inbox for related package when an issue has been marked as fixed and in Inbox.
Even when it only effects a single package (as the page states as an exception to the slice-rule)
> - slice must be formatted like LabelOfPatch-IssueNumber
> for example:
> BadCharactersInPackagenames-2124
> PerformWithArgsPrimFailure-2443
> - reject automatically slices which don't follow the name convention
I sort of prefer:
SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix)
That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inbox, but need to know which issues are safe to close.
Yes, better to have the number before. Maybe we can remove the word slice too: ��XYZM-DescriptionOfIssue.
I think the real trick is to reject (kindly, with lot of explanations :) all slices which do not follow the adopted convention so people follow the rule.
��
We can create a PharoRejected repository to let people know. Then some Smalltalk code scans PharoInbox, move bad formatted slices to PharoRejected automatically. In PharoRejected packages are deleted after 2 weeks for example.
Laurent
��
Cheers,
Henry