[squeak-dev] Inbox and Communication
Casey Ransberger
casey.obrien.r at gmail.com
Fri Apr 15 17:19:49 UTC 2011
The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.
I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.
I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.
Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?
What do the core developers think about this?
I must say, I do like Chris' nag-mail idea.
On Apr 15, 2011, at 9:22 AM, Chris Muller <asqueaker at gmail.com> wrote:
>>> To prevent contributions from rotting I can imagine two strategies:
>>> - automatically reject outdated contributions to a StaledInbox
>> Maybe after 2 months.
>
> But how does this prevent contributions from rotting, instead of just
> changing the place of *where* they rot?
>
> So, in 2 months we come back and proclaim, "Wow, look how *clean* our
> Inbox is!" and we feel warm and fuzzy inside. It's like lying to
> ourselves about the truth.
>
> If something is "messy" and we don't like, I think we just gotta "Do
> It". I'm not opposed to having a "Pending" project, where items that
> we don't yet want to accept or reject, but just want to get out of the
> way for the newest items.
>
> Heck, maybe a simple age-based filter on the Monticello repository is
> all we need! Show the the submissions of the last week.
>
> Please help me if I'm missing something.. Dealing with new code is
> something for humans to do, not the machine. Having some automated
> apparatus automatically moving code around to different repositories
> sounds like nothing more than something additional to maintain, and
> creating, guaranteed, additional places for me to check for things to
> intgegrate.
>
>> This would surely raise the attention on it. But as there is a delay
>> between placing them into the inbox and the commit most of them might
>> not fit anymore.
>> And a discussion is necessary.
>
> Maybe instead of automatically moving them, we should just have the
> system automaticaly prod the squeak-dev list with an e-mail:
>
> Attention: Collections-cmm.123 is now 60 days old.
>
> Or whatever.
>
> One last crazy idea: What if, core-devs who don't process Inbox items
> are relieved of their core-dev status; while those that contribute
> Inbox items that get accepted are eventually promoted to core-dev
> (which is how a prior core-dev would regain his status).
>
> - Chris
>
More information about the Squeak-dev
mailing list
|