[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