community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [proposal] Use JIRA for proposing mentored projects
Date Wed, 10 Feb 2010 16:08:22 GMT
On 10/02/2010 15:58, Mark Hindess wrote:
> In message<>, 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.


> Regards,
>   Mark.

View raw message