Increasing Mentors and Mentorships in the Mozilla project will help us grow more contributors in a way that gives them guidance and an ability to be effective faster.
The Mozilla Security team has championed the creation of a mentor management a Django/mysql tool called KitHerder by a student mentor and that tool is nearing the time where it will need to be hosted and supported .
We feel that CommunityIT is the best place for this to be housed and managed once it is ready as it is ultimately about growing community.
What steps need to be taken to ensure we can transition this tool to stable and proper management once complete and ready for use?
Hi curtisk it sounds great. In the last meeting of Grow Mozilla - CB , I told them about my idea , you can find it here . Well, they suggested maybe all this [ kitherder, buddies in SUMO , guides program] can be integrated and implement it. Whats your take on it?
Thanks for bringing this to us! You’re right, this seems like a perfect example of what we should be maintaining.
Can you give us a bit of background about exactly what the requirements for this are? Not hardware specific just yet, but the application platform we’ll need to build.
Besides that, how much maintenance from our end do you expect this to need? What will be expected from us when this is running? (Except the basics of incident response, security, and general upkeep)
We’re quite low on human resource right now, but this does seem like a good example for us.
It seems that this is a django app with minimal requirements. What we can easily do is set it up in our paas infrastructure (and deploy it to production). Our PAAS infrastructure is based on Stackato and has been successfully tested for MozModerator (in terms of deployment and production usage). Plus it would easily give us a *.mozilla.org domain. Does this make sense?
If this is just simple django, then that would be the option we’d take anyways, more than likely. And you’re right, PaaS infra is approved for mozilla.org
Regular types of maintainence should pretty much cover it, development is happening on Github, and I don’t anticipate doing regular releases other than security fixes if any are needed. That part needs to evolve and a decision on how often to update should be discussed.
We don’t anticipate that this will need lots of support/person hours, as user administration should be handleded in the application as far as I understand.
I sent you an email - but will respond here as well. That I am interested in leveraging this for the Guides program. Would it be possible to have a quick call/demo in the near future?
Thanks,
I think the next steps are for Renee and I to commit the most recent changes back to the public repo (including some stability and deployment fixes to support modern security features), then work with community IT folks to get it set up.
How does Community IT track stuff? Should I open file some bugs, or is discourse the correct location?
We’re still trying to figure out the clear balance between Discourse and Bugzilla as it pertains to getting things done, but I think bugs would be awesome (maybe a tracker bug for the site going up and individual bugs for the tasks involved).
Yes, if there is a clear task to be accomplished file a bug, and then link it to the discourse discussion.
Topic of discourse thread should be edited to include [Action] so that it hits our radar on the triage meetings.
If we have to make a decision on something, ie are we or aren’t we going to do x? Then that generally happens on discourse and should get the [action] heading, but doesn’t necessarily need a bug.