is no one maintaining flow anymore?

[iFun]

the PR,commits and issues are over 1 years old. Maybe if you guys are can add other people to the team so we can keep this awesome project alive

[jlfwong]

@JGulbronson is the de-facto maintainer at the moment, but I'm guessing his time is running pretty low.

I think none of us have any fundamental problem adding people to the team, we just haven't had much interest (though we admittedly haven't advertised very widely).

[iFun]

@jlfwong I think you can just find someone to review PR and merge will be fine. I saw lots of opened PR. I am sure that UW students will happy to contribute to the code base.

[Tylermarques]

@jlfwong I think if you were to send an email to CS Club, they probably have at least a few students who would like to contribute but @iFun is right, someone would need to review and approve PR requests. You could even look at making UW flow something CS Club supports, and could be an on going project for them. It's still incredibly useful for many students here.

[sbobkin]

Hi, worth contributing to this conversation the Open Data API that you currently use is now in a new team at Waterloo. We plan to make changes around it and at some point in 2018 deprecate much of the existing API. I've tried to reach out to the existing maintainer, but have not heard back.

[JGulbronson]

@sbobkin which email did you use? I don't think I got one from you, though perhaps it went to my junk folder?

@iFun I can try to go through those PR's when I get the chance, but they're fairly old and small. I need to do another sweep of the PR's and Issues again.

I agree we need a new maintainer, currently I "keep the lights on". That is, keep the certs up to date, deal with digital ocean, and inquiries from profs when necessary. I'd love to have people who could give it some more time, and I think the first step is getting them to put up PR's. Ownership of the project doesn't change someone's propensity to contribute (or at least I hope not), and I'd want to see a couple PR's merged before handing off the project.

Hope that makes sense, and if you know of anyone who would like to contribute, please point them my way!

[sbobkin]

@JGulbronson it went to your gmail around September 20th. The gist is we're going to be redoing the API going forward. There are some underlying data model issues that lead to inaccurate data that cannot be resolved as is. We wanted to give the top users as much heads up as possible. The current API won't go away immediately, but we'll be giving approximately a 6 month window to switch once an equivalent replacement data set is released.

[iFun]

@JGulbronson The issue with no one wants to contribute anymore maybe because

1. PR never gets merged(no point of opening PR, if never gets merged) also small PR still worth merging
2. Issues are not labeled. New people see all the issue does not which one is OK to work on
3. Issues that is out of date or no long valid is not closed
4. People don't know what new feature is plan to do

if you take a issue that is not labeled and fixed it, open a PR that does not get to merged in one year, it's kind of suck. I understand that ownership should be earned. However, I think anyone who see the repo and see the current status of the project. I think even if they want to help they are afraid that their work will be a waste of time.

I mean there is still a PR thats opened from 2014

[jlfwong]

@iFun These are all good points, and thankfully many of those are relatively easy to resolve.

PR never gets merged(no point of opening PR, if never gets merged) also small PR still worth merging

We can resolve this by closing out old PRs that no longer apply (FWIW, the PR from 2014 was from a friend of the original maintainers who doesn't even attend UW, so they were not a candidate future maintainer 😄). But I agree that it gives the impression that the project is unmaintained.

Of the remaining PRs, many of them are from the maintainers themselves, but I agree still give the impression of little to no maintenance, so we should close those out too.

People don't know what new feature is plan to do

There is no plan 😄. So it's really up to contributors to propose features they think are valuable.

Regarding the other two issues:

Issues are not labeled. New people see all the issue does not which one is OK to work on Issues that is out of date or no long valid is not closed

Here's a somewhat sad truth of the project: it's now been 3 years since the original contributors graduated. Given the nature of UWFlow, we are no longer users of the site, and haven't contributed much since 3 years ago. We aren't really ramped up on the codebase any more, and our motivation to set a roadmap or actively seek new maintainers is pretty low.

Doing issue triage and PR review is a time burden, and one that doesn't have a significant return on investment for us. We have a strong interest in ensuring that the site at least stays functional, but our incentive to see it grow and expand functionality isn't all that strong.

I understand that ownership should be earned.

This is true, but not because I would only feel comfortable handing over ownership to someone who's already made a ton of contributions. It has more to do with commitment than demonstration of effort.

Let's use the UWdata API changes mentioned by @sbobkin as an example.

Presumably the APIs we're using are going to eventually stop working, which really would bring the site functionality grinding to a halt. This is now a critical issue that we either have to address or declare the site dead.

If someone pursues writing a pull request to address the problems, we would certainly try to offer help where we can, but ultimately what we need from the contributor is commitment to resolving any issues that arise after their code change. We don't have context on the codebase any more, so we can't act as confident reviewers. So after the PR is merged, stuff might break -- what we're looking for is trust that the contributor will view fixing the fall out as their personal responsibility. If they do, at that point, I'd be more or less comfortable giving that contributor commit access.

It doesn't matter to me if that PR is that contributors very first contribution -- it's commitment to follow through and resolve issues that I care about.

So @iFun, are you interested in taking on a role with UWFlow? Would you personally like to address some of the very valid points you raised about the repository? It seems like you're in 4A at the moment, but that might still give you enough time to build the kind of contributor base that would turn UWFlow into an active development project.

[iFun]

@jlfwong yeah, Currently I am doing my last co-op term and I will be graduating 2018 May. The flow's backend is written in Python which is not my area of expertise(I use NodeJS). I can certainly help with the issues I mentioned above(helping with PR, close issue etc). However, in the short time I can't take on the role as main developer until I fully understand the codebase and python. I think I will have more time to learn python after I have full-time offer. If I would to contribute now, I will need someone with strong python background to review my code and point out my mistakes.

I think I will have more time when i graduate for sure.

[JGulbronson]

@iFun happy to review PR's. I'm currently working full time while finishing school, so needless to say my time is pretty limited right now. The load should lighten up a bit in the new year.

@jlfwong did a good job of commenting on and closing old PR's. I made sure all our issues have labels, of which 23 have the easy fix label. Those are likely the best place to start.

Like Jamie mentioned, Flow doesn't really have a long term plan. I've been maintaining it, but there hasn't been any new features in a while. However, the repository is out in the open, and anyone is free to submit new code. I will try to do a better job of watching for new PR's going forward.

Ultimately our dependencies are pretty old at this point, and that can be a major limiting factor for those interested in contributing. Old Mongo, old Python, old libraries. This should probably be a larger priority than it is, much like the issue @sbobkin mentioned. Perhaps we can put together a list of items that might represent long term and short term goals, and add it to the README. @jlfwong thoughts on that? I'm thinking things like fixing the OpenData API integration, making it easier to get setup locally, etc.

Also thanks for pointing out those super old PR's and Issues, from way back in 2014. I think that was before I took over officially, and I never did a thorough cleaning. Hopefully the recent changes will encourage contributions.

I've tried to invite people to contribute in the past (see this Reddit post for example: https://www.reddit.com/r/uwaterloo/comments/73iiuc/searching_for_a_new_uw_flow_maintainer/), but nothing has ever come of it. Any suggestions to encourage contributions would be welcome!

[iFun]

@JGulbronson I totally agree there should be a list of items with long term and short term goals

• update out of date packages

• update to python3?

• remove out of date TODO comments(I saw lots of TODO in the codebase)

• better testing environment? so that we can have a PR environment for test

• better doc for new contributor

• update Open Data API

[arumoy-shome]

I think that this project is highly valuable but it has peak times i.e. course selection week which might be a reason why there isn't much interest during the term. If that is the case then developing features that align with the above statement might be a path worth exploring for the maintainers.

Side note, These sets of documents are a fantastic read for all open source contributors and maintainers.

[arumoy-shome]

From the README:

Why RMC?

It might seem funny that this repository and a bunch of the code references rmc.

RMC stands for "Rate My Courses", which was the prototype name for this project before it was given the (slightly) better name of Flow.

Because of the profileration of this 3 letter prefix throughout the code, and the unfortunate coupling of the repository name and our python namespace, we decided to leave it be.

I think dealing with the coupling should be the place to start. 😅

[jlfwong]

I think dealing with the coupling should be the place to start.

While that is a silly bit of legacy, I respectively disagree :)

Of all the technical debt that exists in some form or other in the codebase, that is one which I think least impedes contribution to the project, and the completion of that task would not yield any benefit to students, nor would it provide confidence that the contributor has made a significant commitment to the project or attained proficiency in any area in particular.

As the result of those things, my suspicion is that it wouldn't be much fun for a contributor.

If someone is particularly fired up about doing that and confident that they can do it in a way that won't destabilize the codebase (one massive downside of changes like this is that they're ripe for merge conflicts), then go for it! But I'd rather not propose that as a starting place for newcomers.

[arumoy-shome]

@jlfwong thanks for clarifying. 👍

[sgaweda]

How can I contribute if I'm relatively novice as a programmer? I'm about to enter 2B and would love to make some contributions to an open source project. UWFlow has been my favorite source of information on profs and courses, so it would be an awesome project to work on.

[Tylermarques]

@sgaweda You don't seem to have much on your github yet, and here isn't the place to discuss it, so send me an email and we can chat! (Email is on my profile)

[JGulbronson]

@sgaweda there are some issues marked as easyfix which are good places to start. The first step is getting Flow running locally, then you can tackle one of the issues. Feel free to message me for more info.