How will we report time?

[eak24]

We need to somehow report time in a way that doesn't replicate any work (not a logbook to be filled in) as this would cut into productivity and is already done in issues. There are various options, the most common are toggl, harvest and everhour. However, the cheapest of these, everhour, comes in at $5/user/person. What is the max we can pay for such a service? I sent an email to everhour asking for a discount.

[eak24]

There's this project: https://github.com/timeglass/glass and it uses the meta data in git commits to record time spent and hence can be queried. However, it appears to be an old project that isn't maintained, so perhaps we want to instead just use the meta-data method they use, but not necessarily the actual time functionality...

[eak24]

Also, CUSoftware responded and they will not be able to help us. Their email is here for posterity:

Hi, Ethan.

The CU Software Licensing Office does not at this time manage the license of any time management software product.

I am not familiar with this sector of the software market, and do not have a product recommendation for you. I don’t have record of receiving any other requests for student time-tracking software at this time.

This office no longer has the resources to do product feature assessments or new product recommendations. However, if you have settled on a product that you believe would benefit from University-wide licensing (whether through a site license or volume-purchase agreement), we can evaluate the economic feasibility of central licensing, and, assuming a positive assessment, potentially add the product to our portfolio. An overview of our license feasibility assessment process can be found at: https://it.cornell.edu/software-licensing

Just to set your expectations: Assuming that all assessments and negotiations are positive, it usually take between four and eight months to move a potential product from the initial assessment phase to being able to offer it as a product in the CU Software portfolio. If you would need to use this product in a shorter time-frame, I would recommend working out your own local contract with the vendor.

Please let me know if you have any questions or if I can be of any further assistance in this regard.

Have a great day!

Sincerely,

Mike Ferdinando CIT Support Services Service Manager – CU Software 120 Maple Ave, Suite G32, Cornell University, Ithaca NY 14853 cusoftware@cornell.edu | 607-255-5500

CU Software is a joint service of Cornell Procurement Services, The Cornell Store, and Cornell Information Technologies

[eak24]

How is this going? Did you see the glass commit meta tag options? Whatever you decide on, it might make sense to include this change in the encouragements tutorial so that they understand the time recording expectation right off the bat!

[aadilzbhatti]

Glass is actually pretty nice for what it is. We don't get the GitHub UI integration that Everhour gives us, but it does log the time spent working on a file in the commit message & we can configure how the time spent looks in the message. In addition, it does not require a lot of work on the developers' part: a glass init will handle all time-tracking and commit logging by default.

One thing we do need to consider is querying. Since we need to easily get time data to log hours, this will need to become something that the team leads will need to be familiar with. It looks like their guide provides some of the useful queries and they look easily extendable. All in all, I think this is a good and easy choice for us to use.

What would be the next steps? Changing the encouragements tutorial & then pushing this out to the team leads?

[eak24]

@prevosis I'm glad that glass will work. I haven't tried it. The issue I see is that it only tracks when you are coding, so it incentivizes coding all the time, but I think some of the most important aspects of making a sound program are the communications involved in developing and maintaining sound interfaces. However, it appears to be the best available to us, and Everhour won't budge on their pricing.

I think adding this to the Encouragements tutorial is a great idea. Also adding a page with instructions about how AIDE specifically will use it (maybe linking to the tutorial when necessary) would be helpful (this would be added to the aide_tutorial wiki.)

Might be a good idea to have a section in that new page that describes querying, etc. I think for this to be useable, we'd need to teach everyone how to:

• install and init glass
• edit time submissions before commiting
• edit time submissions after commiting and pushing with a git force (note this is dangerous... not sure what we should do about this.)
• query for time use Before times are ever sent to the advisors, it would be nice to ensure everyone reviews their time spent on glass, and either accept the time, or add a little addendum about additional things they were working on....?

[aadilzbhatti]

Sounds good. I'll get right on that.

I'm looking at the wiki for aide_tutorial...should I be editing this directly or is there some other way that these docs are being written? I'm referring to the line that says "Do not edit here, run DocToc..."

[eak24]

Just the Table of Contents is written automatically. The rest is manually. You just run doctoc again (I think it's a node module on npm) and it autogenerates a TOC

[aadilzbhatti]

Added the time-tracking stuff to the encouragements tutorial and a new wiki page for using glass: https://github.com/AguaClara/aide_tutorial/wiki/Tutorial:-Automated-Time-Tracking-via-Glass. Let me know if you'd like me to make any changes.

[eak24]

@prevosis this looks great! My only comment is that you and Alyssa may get tons of questions about editing time submission - I recommend explaining a standard method. I agree using -f is too dangerous, so perhaps you should recommend they add another commit where they explain what they did. Perhaps you could have them include the time they missed with their next commit, and add a meta tag to the commit like this, for example: --not-code-work: "I worked on this issue and that issue by defining things on the wiki, emailing x and y, etc..." Otherwise I'm afraid we are encouraging ONLY coding, whereas communication and brainstorming is very important. We need to make sure everyone feels entirely in charge of their reported time. (Frankly, I think time reporting is a little unnecessary if you are all working in the same place at the same time!!)

[eak24]

@prevosis @matanp @st587 @ach238

Hi leaders,

We will now be using Toggl as the tool to track time. It has an extension for chrome and firefox and will link directly into emails, github issues, commits, google keep lists, google docs, etc... I will be making you admins on our workspace so you can pull in your team when the time comes around.