cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Graduating.....
Date Wed, 08 Aug 2007 05:45:19 GMT
I wonder if we can categorize CXF developers (or potential CXF developers) into following types:

1.      Developers who were sent by their employers to work on CXF.
2.      Developers who is the current user of CXF. They run into bugs or missing features
in CXF which may block their own project. Instead of sitting back and waiting, they would
like to get these bugs/features done by themselves.
3.      Developers who is generally interested in contributing to CXF, but different from
#2, they do not have any thing specific/immediate to start with.

I wouldn't worry about type #1 users at all, they shall have initiative strong enough that
if there is anything coming out of their way, they will shout out. For #2, I believe we've
been doing good so far, through mailing list, JIRAs, IRC etc. Anything we can improve to help
them getting involved more easily?

For the #3 type of users, the story is a bit different. This is the area I believe we should
put more care on. As this type of potential developers don't have any specific areas to start
with in the mind, they often have problems to find an appropriate task as starting point.
Of course they can still watch the commit emails to understand who is changing what code,
they can walk through JIRAs to know what stories are available, but this doesn't help them
too much to draw the big picture. I.e., what are the main stores CXF community is working
with, what are the schedules and status of these stories, what has been finished, what left,
who is working on what. This kind o information is crucial to a new person in order to know
what areas he/she can start with, what stories he/she can pick up which is relatively independent
from other stories and he/she also wants to make sure the story is not on others immediate
to-do-list to avoid conflicts.

Any thoughts on this? One of my comments is we need to make a better use of Jira. The description
in Jira has to be more specific and in details. For example, "Make handler chain working"
would not work. Secondly the ownership of Jira story's needs to be clear and precise. What
strikes a new person mostly is how to find a Jira story that is "available". What we often
see is there are tons JIRAs assigned under one developer's name, which are not intended to
work on immediately. On the other hand, a JIRA without assignee does not necessarily mean
one can pick up this story without conflicting with others, we often see the commit has been
done without corresponding Jira being started or even assigned. Thirdly, an initial evaluation
given by a senior committer on the difficulty and priority of the story would be helpful.
For example, as Dan Kulp suggested, mark the start as "easy/intermediate/hard" etc. The priority
normally is hard to get it right from a new person, as this sometimes involves in the historical
info of that features/bug, who is requesting this fix etc. The correct use of priority in
Jira would be helpful, a new person probably want to play with some low priority/non-urgent
issues as a start.


Cheers,
Jervis

> -----Original Message-----
> From: Daniel Kulp [ mailto:dkulp@apache.org]
> Sent: 2007?8?8? 9:49
> To: cxf-dev@incubator.apache.org
> Cc: Jim Jagielski
> Subject: Re: Graduating.....
>
>
>
> Jim,
>
> I really appreciate the candid response.   Thanks for that.
>
> So, the question becomes: what can we do to help others get
> more involved
> in the CXF code?   That question is open to the non-commiters
> as well.  
> What can we do to help you?
>
> I was sitting around trying to brainstorm with some folks
> this afternoon
> and thought of one idea (I'll give Debbie credit for this): 
> is there a
> way to mark tasks in Jira with an difficulty level?    If we
> could mark
> some tasks as "Easy" as opposed to "Yea Right", that could
> make it much
> easier for a new person to find something to get their feet
> wet.  Jim:
> since you're probably the only one with Jira admin access, is that
> something that can be done?  Add a "Difficulty" or "Complexity"
> attribute with levels like "Unknown, Trivial, Easy, Medium,
> Difficult,
> Yea Right"?   (I know VERY little about what Jira can do.)   If we
> decide this is a good idea, is this something we need to file through
> Infrastructure?
>
> Anyway, to all the non-commiters: I highly encourage you to
> reach out to
> the developers, ask questions, dig into the code, etc...  If you want
> some pointers or need help finding where the code that does something
> is, please ask.  
>
> Thanks!
> Dan
>
>
>
> On Tuesday 07 August 2007 17:00, Jim Jagielski wrote:
> > On Aug 7, 2007, at 12:51 PM, Daniel Kulp wrote:
> > > The main concern, of course, is diversity.   There are a bunch of
> > > IONA folks, however, we do meet the criteria of 3 or more
> > > independent commiters with IBM represented, obviously Envoi
> > > Solutions,  a couple of
> > > independents.   We also have a couple folks that have been
> > > submitting patches and are getting "close".       That all said,
> > > despite having a lot of IONA folks, I think we've done a good job
> > > keeping the development
> > > open and in the community.   That's the more important thing.
> >
> > Keeping the development open and in community is all good.
> > But, imo, as mentor, the diversity simply is not there
> > yet. My general feeling is that if IONA were to drop
> > its interest in CXF, many people currently involved
> > in CXF would go away.
> >
> > I see progress being made in increasing diversity,
> > but CXF is not there yet.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
> 


----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message