XSF Discussion - 2018-01-19

Or... it helped mentors know what students they didn't mentor were up to.

Didn't we had mandatory weekly blog posts and a joined MUC for this?

Not exactly, no.

The blog posts are public-facing and are a summary of the technical activity.

The weekly meetings are for keeping in touch and seeing how things are going and an opportunity to discuss issues, etc.

Nothing which justifies the tradeoff of holding a weekly meeting across all mentors and particanpts

I disagree.

It doesn't have to be a weekly MUC meeting, naturally. But I think *something* of that nature is vital in trying to encourage a culture of being team players.

Surely you must have similar setups in other groups you're with - at work or with customers or whatever?

Kev, if we work all on the same project

We're part of the same organisation.

But weekly mandatory meetings with all particpants who work on different projects are counterproductive

Surely you have colleagues who work on other projects, and it makes sense to keep a sense of what's doing on there.

I know I do.

And the XSF is the only GSOC org who did that I'm aware of

And the comparison with a proffesional paid environment seems odd. As spare time mentor I have to carefully decide how I spend my time, and those weekly meetings yielded nothing in return for me, and possibly for my student. If there had been another XSF GSOC project I had been interrested in, I would probably get in direct contact with the related mentor and student.

Actually that is what I did in 2015 when OMEMO was developed

Flow, but then, getting in contact with specific mentors incurs O(n²) cost "if everyone did that"

while a meeting can be O(n)

Flow, the only other org I was following some GSoCs ago was also holding a similar chat meeting with all students working on different projects.

(Tatoeba.)

Link Mauve, a mandatory weekly meeting?

jonasw, true, but that assumes that everyone wants to know what everyone else does

Yeah.

The biggest gain is probably ensuring that no student feels that they're on their own, or stuck with their mentor if they're not getting on, or the like.

yeah, "if everyone did that"

Link Mauve, and there where different codebases involved? Was Tatoea acting as umbrella org?

In the happy path lots of the protections that an Admin has to put in place aren't as necessary.

But they're there because experience says that when things go wrong they can go very wrong unless you keep on top of things.

Flow, different codebases (the current PHP-based tatoeba2, a totally new Django version, the Qt software Anki, and I think something else too).

I think is sufficent to tell the students that they can contact the org admin if they having issues which they can't resolve with the mentor, it doesn't need a weekly meeting for that

Flow, I’ve noticed that many newcomers tend not to think about going to the rooms of other projects.

Maybe because IM is not fully part of their workflow, or a myriad of other reasons.

Flow, also some people tend not to reach for help when they feel overwhelmed or lost, I know I have that tendency.

Link Mauve, I don't follow, sorry. This is not about having a joined MUC for GSOC, but about whether or neet it needs another additional mandatory weekly meeting

It has affected me quite a lot in the past, until I started seriously working on that issue, people around me would only notice when it was very late.

Flow, looking at other years, there was exactly no discussion in said MUC outside of the weekly meetings.

Link Mauve, there surely was discussion between mentor and student

Maybe in private, and some in the project’s room, but I didn’t see any of that in the shared room.

And I didn't expect that to happen

Shouldn't there be an edge from "Rejected" to "Experimental" in xep1 § 8.1?

Flow, Hmmm. Possibly. I think Council should probably be able to fish things out of Rejected etc, and also push things back from Proposed to Experimental (which I think has happened).

I've whinged about this for years, but never got traction with anyone else to fix it.

No, Council can't technically fish things out of Rejected, or from Proposed back to Experimental, although past Councils have ignored this and done it anyway.

I think XEP1 should be fixed to allow both.

I don't think that it needs council to get from rejected to experimental

Flow, I think it probably does. It's the moral equivalent of resubmitting as a new ProtoXEP.

But without a new number, I hope

How can it be the "moral equivalent" if the previous XEP state was Experimental. What justifies a downgrade to ProtoXEP?