As discussed earlier, I think we are ready to start incorporating fixes & small enhancements from the SQFIXES page ( http://swiki.gsug.org:8080/SQFIXES/ ) into 3.6alpha, even though we still need to discuss the larger items which will make up 3.6.
The process for entering and tagging submissions looks pretty good. I want to nail down the final steps of the process, so that we can start moving stuff into the update stream.
For incorporating [FIX]es, we agreed that the fix needs to be approved by one Harvester. (Harvester meaning a Guide, a member of SqC, or a harvesting volunteer from the original list of harvesters. Hmm, I need to contact the people on that list to see who is still interested.)
To make things clear, the harvester should use a special keyword (which we should agree on now) such as "[approved]" in the parentheses of the SQFIXES entry. That way I can do a simple search on the SQFIXES page to check for recently approved items.
After an item has been approved, one thing that we still want is a chance for other harvesters (and perhaps anyone else) to note that the item is about to go into the update stream, and voice any last minute opposition or refinements. For example, "Wait a second, we don't want to just change frobozz like that... that could cause problems for this other doohickey."
With the previous harvesting process, each harvester had to submit a .zip file of a bundle of harvested changes to a largish list of people, which provided a convenient sort of last-minute screening for things. In theory, we could do something similar with submitting bundles to this SqF list, but that seems a bit too heavyweight for me. Perhaps we should just allow a certain amount of time to pass (say, at least 3 days) after an item has been approved, before it gets added to the update stream. This will give people a chance to say "Hey wait a minute". However, this requires that harvesters do a reasonable job of tracking the SQFIXES page on a semi-regular basis to see what new stuff is about to go in, rather than having a summary conveniently arrive in an email. But I think this is probably workable.
Another thing I should probably do is add one last tag/keyword to SQFIXES entries which are being added to the update stream. It could be ([update]) or something like that. (The 3 day delay could happen between [approved] and [update], or it could happen between adding the [update] tag and actually adding the fix to the update stream. Hmm, probably the former makes more sense.) Realistically, I may only incorporate things into the update stream once per week or so, so the delay could vary from 3-10 days or something like that. But that's still a pretty decent turnaround compared to what we have now.
Yet one more issue is whether we want to have stricter standards for [ENH]ancements. We talked about requiring approval from two harvesters. Or perhaps approval from one harvester, plus an [et] from any other third party would suffice. Hmm. (I suppose one drawback of having stricter standards is that people might be tempted to call something a fix which is really more of an enhancement.)
(I guess this post doesn't cover the issue of whether any of the [sl], [er], etc., tags should be mandatory before an item is approved by a harvester. Certainly any such tags should make it more likely that an item will be seriously looked at. I'd say we could probably get started incorporating stuff without requiring mandatory tags, and figure out which ones really need to be mandatory after going through the process for a little while. Probably [et] and [er] should be required, at least, although the harvester could supply those tags upon approval, if no one else does.)
Anyway, we can try something like I outlined above. Does this all sound reasonable? The only thing I'm still not sure about is whether we want stricter standards for enhancements.
- Doug Way
p.s. Once this is sorted out, I do need to update the various harvesting web pages that Tim mentioned. And yes, a fancier harvesting system will be coming eventually, but probably not for a while.
Okay, there seemed to be some agreement (and no disagreement at least) to the items I mentioned below.
So, I'm going to start incorporating [approved] submissions, with the 3-day minimum delay. We'll see if the 3-day delay is sufficient in practice. If someone else objects or adds further refinements to an [approved] item before 3 days have passed (i.e. before it's incorporated), I'll postpone incorporating the item until the issue is resolved.
Also, since there were no comments about the approved tag, I'm going to say that harvesters/guides/SqC should always use "[approved]", for consistency's sake. It'll make it easier for me to search for approved items, and the brackets make it look more official, too.
When I incorporate a submission, I'll post an entry with something of the form "[update - 5273]" in the parentheses. Might as well include the update number. Since I'm doing that, I may not bother with the [UPDATES] summary emails, since a batch of [update - ...] emails will be coming through anyway.
Also, I will be approving items as a harvester, too. I don't think there's any sort of conflict of interest between these two roles, since the rules for incorporating approved items is well-defined, so the role of "incorporater" is pretty automatic. The role of a harvester involves some judgement, of course.
- Doug Way
On Monday, March 24, 2003, at 07:56 PM, Doug Way wrote:
As discussed earlier, I think we are ready to start incorporating fixes & small enhancements from the SQFIXES page ( http://swiki.gsug.org:8080/SQFIXES/ ) into 3.6alpha, even though we still need to discuss the larger items which will make up 3.6.
The process for entering and tagging submissions looks pretty good. I want to nail down the final steps of the process, so that we can start moving stuff into the update stream.
For incorporating [FIX]es, we agreed that the fix needs to be approved by one Harvester. (Harvester meaning a Guide, a member of SqC, or a harvesting volunteer from the original list of harvesters. Hmm, I need to contact the people on that list to see who is still interested.)
To make things clear, the harvester should use a special keyword (which we should agree on now) such as "[approved]" in the parentheses of the SQFIXES entry. That way I can do a simple search on the SQFIXES page to check for recently approved items.
After an item has been approved, one thing that we still want is a chance for other harvesters (and perhaps anyone else) to note that the item is about to go into the update stream, and voice any last minute opposition or refinements. For example, "Wait a second, we don't want to just change frobozz like that... that could cause problems for this other doohickey."
With the previous harvesting process, each harvester had to submit a .zip file of a bundle of harvested changes to a largish list of people, which provided a convenient sort of last-minute screening for things. In theory, we could do something similar with submitting bundles to this SqF list, but that seems a bit too heavyweight for me. Perhaps we should just allow a certain amount of time to pass (say, at least 3 days) after an item has been approved, before it gets added to the update stream. This will give people a chance to say "Hey wait a minute". However, this requires that harvesters do a reasonable job of tracking the SQFIXES page on a semi-regular basis to see what new stuff is about to go in, rather than having a summary conveniently arrive in an email. But I think this is probably workable.
Another thing I should probably do is add one last tag/keyword to SQFIXES entries which are being added to the update stream. It could be ([update]) or something like that. (The 3 day delay could happen between [approved] and [update], or it could happen between adding the [update] tag and actually adding the fix to the update stream. Hmm, probably the former makes more sense.) Realistically, I may only incorporate things into the update stream once per week or so, so the delay could vary from 3-10 days or something like that. But that's still a pretty decent turnaround compared to what we have now.
Yet one more issue is whether we want to have stricter standards for [ENH]ancements. We talked about requiring approval from two harvesters. Or perhaps approval from one harvester, plus an [et] from any other third party would suffice. Hmm. (I suppose one drawback of having stricter standards is that people might be tempted to call something a fix which is really more of an enhancement.)
(I guess this post doesn't cover the issue of whether any of the [sl], [er], etc., tags should be mandatory before an item is approved by a harvester. Certainly any such tags should make it more likely that an item will be seriously looked at. I'd say we could probably get started incorporating stuff without requiring mandatory tags, and figure out which ones really need to be mandatory after going through the process for a little while. Probably [et] and [er] should be required, at least, although the harvester could supply those tags upon approval, if no one else does.)
Anyway, we can try something like I outlined above. Does this all sound reasonable? The only thing I'm still not sure about is whether we want stricter standards for enhancements.
- Doug Way
p.s. Once this is sorted out, I do need to update the various harvesting web pages that Tim mentioned. And yes, a fancier harvesting system will be coming eventually, but probably not for a while. _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org
-
Doug Way