On 10/02/2010 15:58, Mark Hindess wrote:

In message<4b72976f.9000...@apache.org>, Ross Gardler writes:

[SNIP]

For clarity, lets stick with "mentor" and "GSoC" since Harmony has
already started doing this.

Ok. Thanks.

(note there is still time for objections if people think I'm driing
too hard in the wrong direction).

Agreed.  I'm happy to pull the data from Harmony JIRA and make it
available on a wiki if necessary.

Having had a conversation about potential projects with a couple of
Harmony developers, we've decided to use JIRA assignee to record the
committer that will mentor the project.  For Harmony, if there is no
assignee then there is no confirmed mentor.

Our intention would be to drop the gsoc label if no mentor is found for
the proposed project within the next few weeks.  Ross, is this okay with
you or would you rather we used a "gsoc_mentor_required" label, until
there was a confirmed mentor, in order to keep the project out of "your"
filter.

I think it is fine for you to have an assignee as a mentor. There is no need for you to go through it at a later stage to remove labels. I can provide two searches. One for "mentor available" (i.e. assignee is filled in) and one for "mentoring possible".

I would imagine that if you get a brilliant student offering to do something they may be able to talk someone in the community into mentoring. Lets keep the door open as long as possible.

Historically and no doubt again this year, there will be cases were a
non-committer will be primary mentor with a committer as co-mentor.
In this case, the committer will be the assignee and the co-mentor
arrangement will be documented in the comments/description.

Yes, as with previous years. The committer will have responsibility for all liaison with the admin team. What you do internally on the project is up to you.

I wonder how other project will use the JIRA fields/labels and if it
makes sense to try to be consistent across projects.

It's my intention that the projects will be consistent. Rather than trying to get consensus across all projects I'd rather hammer something out with those here and then tell them how it is going to work. That's why, from my point of view, it is important to do something that does not change their normal JIRA workflow. All I care about is getting the data from them, the projects themselves can decide how to manage them.

Ross


Regards,
  Mark.



Reply via email to