Software Development Volunteer Opportunity for DMS

Hackerspace Software Development
1

Hello everyone!

Are you a beginner or intermediate python/JS programmer (even one fresh out of the tutorial) that needs some development experience on a team and some professional references for job applications so that you can trade your shitty job for a shitty job that pays well?

Are you an extremely bored experienced software engineer who has become so effective that you no longer feel alive at your job where you only need to spend a couple hours a day doing development and the rest of your day watching YouTube videos? Do you yearn for days where you can at least feel bored for a good cause?

Boy, do I have the opportunity for you!

Ladies and Gentlemen, a new DMS calendar is actually happening. This is not a meme or a joke.

A group of experienced developers have agreed to lead a group of less-seasoned programmers in Science Committee’s new Scientific Computing SIG in its first ever software development project: a new DMS calendar.

One of the goals of this project is to teach Scientific Computing SIG members without development experience how to develop software as part of a team so that they can help on future Scientific Computing SIG projects, but you don’t have to stick around with the SIG after project completion to be a part of this!

To take advantage of this opportunity, show up to Scientific Computing SIG’s next monthly meeting in the Lecture Hall on November 2, 2024 at 5:00 PM.

The expected length of the calendar project is 1-2 months. We ask that you be able to meet at least once a week either through face-to-face meetings or on google meet, and that you have a basic understanding of Python, git, HTML, and CSS. Doing a Python tutorial, a git tutorial, creating a github account, and watching (actively!) these tutorial videos on HTML and CSS before the meeting on November 2nd is sufficient for meeting the minimum requirements of being on the team for this project.

Our goal is to get 12-15 people to show up on November 2nd.

Thank you,
Kevin Thompson

7 Likes
2

Love the idea of killing two birds with one stone. The current calendar is a bit of a mess could definately use an upgrade.

Edit: I’ve also never been one who loves to do exercises with no real application. So excellent choice.

1 Like
3

Love the idea of a new calendar and you have my support (wearing my CTO hat) however do keep in mind that a useful calendar system must interface with our existing SSO, Finance, DB, accounts and other systems depending on the scope of any actual effort that takes off.

Is anyone from the IT team supporting this effort?

1 Like
4

I’m potentially interested. “Learn Python” and “Learn Git” are on my list.

If all the meetings are weekend afternoons though, that will be a problem for me.

1 Like
5

We can work around schedules and meet different people at different times!

1 Like
6

I appreciate the support! I asked Mark and he agreed to help. Yeah, I see there are several systems to interface with and there will obviously need to be some managed effort to understand the various interfaces even if we have someone who already understands them. Any help or advice will be appreciated!

1 Like
7

Hey Todd,

I’ve taught some Python and Git classes at DMS in the past. I can forward you the lecture notes if you’re interested.

8

Please do. Thanks !

9

I know some python and have taught it to middle schoolers for 4 years. I’d love to help, but I probably need some catch-up since most of what I do is basic flow control stuff for kids to learn the basics.

10

I note the conspicuous absence of any requirements document or functional specifications.

That may not be a fun part of software development, but is necessary for something of this scope and importance.

Earthlink rewrote their web mail interface and it has been a massive piece of crap since.

1 Like
11

I know enough python to be dangerous and understand HTML and react. I don’t have any JavaScript experience.

I’d love to join and help out. I’m pretty knowledgeable in AWS/APIGateway if we need to use that for integrating with a backend.

I’m also product manager so I can help with managing the project with, reqs, documentation, Jira tickets, Kanban/Trello boards, anything like that.

Random question do we have any development guidelines, documentation guidelines, or anything of a software architecture rules for publishing code at DMS?

1 Like
12

@kthompson395 is going to involve everyone in the requirements process.

1 Like
13

If the documents are already in place, that schedule may be doable.

1 to 2 months is a very short time for a project like this. Just saying…

1 Like
14

Guidelines and rules will be discussed at the meeting.

15

Whether or not the schedule is met is of tertiary importance. What matters is whether this gets done.

If it takes more time then we expect or more time than most people involved are used to spending on a project and they want to leave, then we’ll deal with that issue when we get there. Note that if we don’t get everything exactly right the first time, we can always improve later. One of the issues with the current calendar is that there is far too much friction for volunteers who want to improve it.

There are going to be many, many things in this project that other people, including yourself, will know more about than me. I did not announce this project under the assumption that I already know how to do every single aspect of this project correctly, so I would greatly appreciate any help I can get. Do you want to assist us in this project?

16

I am curious what you mean by this… And also curious on how you are planning to combat the same issues.

17

First, it’s far easier to find Python programmers than CakePHP programmers or any other type of programmer at DMS. We should probably be doing everything we can in Python instead of whatever a given volunteer wants to use in the moment. We want to minimize the amount of things a new volunteer needs to learn in order to contribute. Every little additional friction adds up over time and saps away at the pool of potential volunteers. We want to make it as easy as possible for people to volunteer (but no easier).

Second, there are certain things that should be managed by committees, such as the spaces or tools in the Calendar (for example, Science committee’s Fume Hood). Adjusting the calendar should be done by certain privileged users of the calendar when possible, otherwise IT becomes a serious bottleneck (friction) when committees want to pivot in a certain way that forces them to reorganize their committee space (which means changing what is in the list of rooms, for example) and they need to keep bothering IT to actually make these fairly simple adjustments.

Third, we need standardization. @jphelps brought up several examples the other day related to using the same systems the rest of DMS uses for sign-on and payments. For example, he wants us to move away from braintree, which is what the current calendar uses (assuming the documentation is still up-to-date), and towards authorize.net. This is another example of minimizing the amount of things a new volunteer needs to learn.

1 Like
18

I mean, I don’t see how any of those things are friction for the current development other than the PHP side but -shrug-

I’m not disagreeing that the calendar needs work and/or to be rewritten but I’m not sure I agree with some of the statements made about it or the planning behind some parts.

19

Here’s the thing: you may be right. I take your opinions very seriously and so there may very well be mistakes.

Ultimately we are going to get some things wrong. My goal is that, when we do get things wrong, that we at least make it as easy as possible for people to fix whatever we do wrong by giving more customization options for committees, officers (particularly education coordinator), and board members. This means they don’t have to bother IT volunteers who almost always want to work on other, bigger IT problems at DMS. This also means making things as easy as possible for new developers to get involved by minimizing the amount of things they have to learn. This means there are more potential IT people around to respond to committee needs.

If we get nothing else right except those things (and also of course the necessary security stuff and integration with DMS’s existing systems), then I will still consider this project a massive success.

The central (though probably controversial) philosophy behind the biggest calendar changes I want is this: getting consistent, good volunteers outside of committees is far, far harder than getting consistent volunteers inside committees, regardless of who is on the board or who is leading logistics or who is leading IT.

The problem is that DMS is not a third space, but a collection of third spaces. For example, DMS as a whole isn’t the third space of creative arts folks; the creative arts area or the Sewing area are. Same thing for science and most other committees. Consequently, one has a far easier time getting volunteers from committees. People fight harder for their third spaces than for the collection of third spaces. People fight harder for their favorite bar than for the city the bar is within, even though the bar needs a city to do well.

The calendar is deeply tied to the well-being of each committee, and we need to give them the features they need to make sure that they can make the calendar meet their needs when their needs change. That means letting them control the list of spaces and tools in their committee directly, that means allowing classes to be multi-room with different times in each room, and so forth. That means letting education coordinator or board or some joint-institution of committees in an area control the granularity of flex spaces so that partial or full capacity can be reserved, allowing for multiple classes to be scheduled in the same area at the same time. This also means making it easier to build a large pool of IT volunteers by minimizing the amount they have to learn.

20

Can you DM me your email so I can send it over your way?