Community IT managing KitHerder

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?

1 Like

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? :slight_smile:

Hey @curtisk

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.

Hey all!

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?

1 Like

I can deploy to AWS.

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 :slight_smile:

The PaaS is the best place for this.

I’m not sure this group has the right structures in place to support this yet.

1 Like

Very true. @tad, let’s stay away from deploying things to AWS until we have the authority and flexibility to do that.

1 Like

I meant to say I can deploy to PaaS. Not AWS.
Whoops!
Sent from my iPad

As noted it’s a django/mysql (thank @pierros).

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.

Hi Curtis,

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,

-Emma

Hi emma,
sorry been busy fighting fires.
I will repond to your email to get more specific as it’s off topic for what’s happening here.

Hi Curtis,

I hope the fires are not bothering you anymore :-).

I’m in the same wagon as Emma - would love to talk more about using this for L10n projects. Any chance for a meetup?

Thank you!

1 Like

I will be happy to help in any kind of help that might be needed

I’d like to reignite this conversation and learn what it would take to migrate this over to Community IT.

What’s a good next step?

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?

Bug please - https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations and pick Community IT: Hosting.

(welcome back from vacation?)

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.