Using Gitlab to replace the Contributor log

What kind of hours are people currently reporting? Are all of them the kinds of things that would have a l.c.o issue? E.g., I recently reported several hours spent working on the Establishment Committee, and as far as I know there's no l.c.o issue for that. How are such non-issue-related tasks to be reported? (I'm hoping the answer is not "those contributions don't count and need not be reported.")

That's a feature! It reminds us of the importance of creating issues (i.e. documenting). For the EC, we should have created a Gitlab space much earlier in the process.

That said, it won't be as straight forward to log time for:

volunteering on Stack Exchange,
responding to folks on Mattermost,
meetings (ex: regular WG meetings)

I guess the easy solution is to have generic issues for tracking time in those areas, but I don't have a strong opinion. Sounds a bit unpractical, and as with the Contributor Log, it doesn't leave a clear trace. Ex: say someone adds 10h for "chatting on mattermost", how do we review that? (it's also a problem in the current Contributor Log)

Right, the challenge is somewhat elusive; self-reporting is kind of an honor system anyway; it's hard to verify everything.

My main concern is that we have a way to continue reporting those non-issue-related contributions (meetings, user support on other platforms, etc.). Sounds like you're trying to find a way to support that.

I'm okay with creating generic issues for helping out in various spaces.

What is the /spend mentioned? It looks like it may be some command line tool.

You can type, for example /spend 15m in the comment box.

(it should auto-complete with details of the syntax)

Hmm. When I try that I get autocomplete for other commands but not for /spend. Are there permissions for that command in particular that lead to you getting autocomplete?

¯\＿(ツ)＿/¯

Can you try again? You were not a member of the infra project.

added 15m of time spent at 2019-07-03

worked.

I tried /todo but don't know where it went ;)

added 15m of time spent at 2019-07-03

I had configured this project with the wrong punch alias, but here's an example of what we see in CiviCRM.

I'm still not convinced that recording "contributor hours" adds any real value to the project, but it certainly does add more overhead/support to manage it.

Most of the time I don't log any contributor hours, then every now and again I go and add a chunk but the "contributor badges" have been partially broken for quite a few of us for quite a while anyway. Why not just get rid of the whole "contributor hours" thing and simplify things a bit for those that have to support the civi infrastructure.

If "something" is really needed, then why not develop something automated that pulls stats from mattermost, gitlab, github to track "engagement". It's going to be far more accurate than what we've got at the moment which relies entirely on an honesty/remember to track hours and most likely is way off reflecting the true levels of contributions. Also, "empowering/sustaining/supporting" mean nothing to me and as far as I know it's not explained anywhere - it certainly doesn't indicate that one is "better" than another.

(preface: I agree with your post, but I'm trying not to go down the rabbit hole)

The badges are a separate issue and indeed need to be fixed, but the Contrib Log doesn't add much complexity there.

Whether we want the Log or not, I think will always be controversial. Quite a few people use it and seem to appreciate it. I personally have mixed feelings about it, but I don't think there's a perfect solution and it sort of works well enough.

Using Gitlab to track time is a way to provide near feature parity, removing some custom duct tape (the webform), while piggy-backing on other tools we are already using. The time tracker adopted a while back so that the CT can track time (previously, only work sponsored by members/partners was tracked).

In other words, this issue proposes to remove a few customizations on civicrm.org, has a small impact for those logging hours, but otherwise not a big time investment.

I don't record my hours, but if I wanted a listing on /experts I would. For someone like Rose (or Sean) - she wouldn't be listed there without the contributor hours she posts, so ditching them would exclude her. Personally I think it's nice that donated time is weighted as much as cash, it's a good part of CiviCRM's culture. Tho I agree I havemn't much clue what the difference between 'empowering/sustaining/supporting' is! Maybe one badge would be better (with a profile showing the hours/issues maybe)

Regarding the broken badges - there's an open issue on the subject: marketing/civicrm-website#111 (closed) - I wonder if ditching the custom extension and using CiviRules and tags might do it.

Like mathieu, I have mixed feelings about this as well. On the one hand, it's tedious and imperfect. Many of our strongest contributors don't record their contributions either as a result or merely on principle. But, on the other hand, we are tasked with cultivating and growing a community of contributors. How do we do that if we don't "know" what they're contributing?

Michael once created a "leader board" of sorts that scraped our infra and listed contributors. We got a little backlash for that. One comment that always stuck in my head was from an avid contributor... "people that are contributing know who contributes most already, so having a leader board is pointless".

But, then as @nicol pointed out, some do do it for the recognition (the logging, not necessarily the actual work), and it is in our interest to recognize and promote them, after all they're giving the project free labor, right? But then even Nic himself doesn't record his time (or see a need to be displayed on the partner-contributor pages).

It's imperfect for sure, but shifting to Gitlab should be, as mathieu said, a reduction in overhead.

Re: the badge levels, this page used to be on c.o, but was migrated here a while back. It should be made more visible.

I think in general the badges, and the levels, are more vanity than anything and I'd be a +1 to reworking them. I don't think users look at the badges and say "hey, this person is sustaining level!". Personally, I think we should merge many of our "supporter" programs into one and focus on recognition and on messaging "why it's important to support CiviCRM" in the first place.

Update various gitlab pages and pages on civicrm.org with information on the process of tracking contributions through Gitlab. Pages include:

added 1h of time spent at 2019-07-09

A few points raised by @JonGold and other mattermost discussions:

We need a way to track contributions to Stack Exchange, PR review, and other tools not on Gitlab. In the mean time, this could be generic issues somewhere?
- edit: timetrack/import
It would be nice if we could /spend on an MR (ex: Stripe).
Need to double-check punchs that may not have been added to civicrm.org
~~We need a 'task' to validate punches and create the contributions.~~
- edit: won't do this for now, hoping that transparency will be sufficient.

Note for me: batch-adding webhooks to groups:
https://lab.civicrm.org/infra/gitlab/wikis/timetrack-webhook-script

Having issues with people who started punching already after seeing the blog post, but not all projects were setup yet:

https://lab.civicrm.org/infra/gitlab/wikis/timetrack-gitlab-sql

Can import with the timetrack import.

That first point from @JonGold is key from my perspective: a lot of work (maybe most?) doesn't involve GitLab at all. Having to go to GitLab isn't more work than going into the existing form, but there does need to be a generic issue.

As a related note, our workflow (and that of a few others, if I recall) is to record time in our own Redmine (alongside time billed to clients or spent on internal projects) and then do a batch contributor log at the end of each month. (I'll annotate it to say how much time on each thing.) Considering that most stuff isn't a GitLab ticket anyway, a generic issue would allow that to continue.

Recording time ticket-by-ticket in each sitting seems well-suited for individual contributors who are working directly with GitLab issues, but there needs to be a reasonable way to handle batches.

Finally, @bgm said to @JoeMurray,

Can you try again? You were not a member of the infra project.

Most people aren't members of most groups. It looks like only 22 of us are members of this group, which means that someone else looking to record time here would need to pester someone to add them, wait for them to do it, remember how much time they had spent, and then record it. A generic issue would be helpful for bridging that. Maybe even if there were a standard like /spend 20m infra/gitlab#22 the script could apply that time to the listed issue rather than the generic one.

@andrewhunt Yep, we have a feature on civicrm.org currently not exposed to non-admins, that allows to copy-paste a series of punches. It does not communicate to Gitlab, but it could be an alternative for those who prefer to copy-paste their time logs from other tools.

The syntax is: 2019-07-01 20:30 ct/dev [mandatory comment]

however, folks would need to know what the codes are, but they are rather intuitive - and we can post a help text in the wiki.

The downside is that such punches would not be visible in Gitlab (and I would rather not create a two-way sync), but the Gitlab integration only aims to make it easy to enter time.

@bgm that would be awesome. I think there might still need to be a generic issues for StackExchange and PRs that lack GitLab issues, but this certainly helps our situation--I could export our internal log, make sure it's formatted right, and then paste the entries in.

Agreed with @andrewhunt - his workflow closely mirrors mine (s/Redmine/Invoiceninja/). This would save me a lot of time.

I am completly lost now. Dont know how to enter the time. Don't see what the advantage are as well.

There's info online here and more detailed instruction about GL's time tracking as well.

I think the idea here is to make it easier for more people that interested to jot their time down. We've been pushing more and more to GL and are relying on it as an overall project management tool. Punching time is optional, but the thought was that if you're in GL already, then it's quite easy to just record your time.

To @jaapjansma 's point (I think): this change calls for documentation; and probably this change has not actually happened yet and will be properly announced (in MM #partners perhaps, and elsewhere?) in advance. @josh or @bgm would you agree?

Correction: okay, maybe I missed it, but https://lab.civicrm.org/community/community-engagement/wikis/Tracking-Contributions explains that this is already in place. But the "Log Contributor Hours" webform on c.o is still active. So maybe this change is already partially underway.

But an actual announcement is on it's way, right? Would you like help writing that?

There's also this:
https://civicrm.org/blog/josh/revising-the-contributor-log-enter-gitlab

edit: The webform also still works for now. The plan is to remove it by July 15, but we should probably extend to the end of the month, so people who copy-paste from another time tracker have time to adapt their workflow.

Haha, you can learn a lot by reading the blog. :-\

Just cross-referencing here some of the conversation happening elsewhere: already this change is being cited as a major factor in prompting some changes that I fear will be disruptive to new contributors (documentation/docs#23).

I don't think this is a bad feature on its own, but I suspect that adopting it will prompt a bunch of other changes, too. Maybe it would be best to slow the roll-out for a bit and let this issue be an opportunity to discuss the consequences of this and work out a roadmap for adopting it.

For example, here are some things that have come up already along with the prerequisites for them

document how to record time on the issue (mostly done)
make it easy for someone new to quickly open a PR/MR against a GitLab repo (https://lab.civicrm.org/documentation/docs/issues/23#note_20465)
consider moving docs to GitLab (documentation/docs#23)
document how to record time through the punch codes (#22 (comment 20339))
create a generic issue for StackExchange time
create an issue for handling time on core PRs that lack issues (or reconsider allowing PRs that lack issues)
document whether logging time on any issue in GitLab works or whether it has to be in certain groups
document how to join a group so you can log time there (#22 (comment 20026))
turn off the old contributor hours form

This is surely incomplete, but you can see it's already a decent-sized list. I'm concerned this roll-out is rushed.

Exposing this form on civicrm.org (currently not exposed), should address all of those points. It will provide feature-parity with your current workflow, while allowing us to have more granularity on time reported:

Whether docs move to Gitlab or not, is up to docs. I always encouraged folks to use Gitlab, because it provides the best structure and discoverability, but would I prefer that decision to come from docs folks. If there's no consensus, then the CT can weigh in.

I have no preference for GL vs. GH for docs. And thanks for exposing that form, I'll test it in the next day or two with the pro-bono hours I couldn't log to GL earlier in the week.

added 30m of time spent at 2019-07-13

The import UI is now fully tested and functional:
https://civicrm.org/civicrm/timetrack/import#/import

I also exposed a report to view recent punches:
https://civicrm.org/civicrm/report/instance/81?reset=1&force=1

both have been added to /user.

I think this resolves most of the issues around tracking non-issue time, and partners copy-pasting their logs. The wiki page has also been updated.

Next step: update the code for partner badges.

I read Josh's blog and I've read through most of this above, but it's hard to follow and I'm a bit lost.

I tried to follow it on a new issue I just researched. I put /spend 1h at the end of the issue, but nothing's come up in the sidebar where it says Time tracking.

I suspect I'm not allowed to contribute hours to the project now? ;-)

@artfulrobot

Gitlab requires to do the /spend 1h in a separate comment.
Added you to the dev group (you need to be part of the group/project, with reporter access, or more).

Thanks @bgm, appreciated!

As for where to put it, git lab says (emphasis mine):

Quick actions can be used in the body of an issue or a merge request, but also in a comment in both an issue or a merge request.

So is civi's set up different to the normal?

My bad - that does seem to work. I guess the only problem was that you were not a member of 'dev'. i.e. item (1) here: https://lab.civicrm.org/community/community-engagement/wikis/Tracking-Contributions#tracking-contributions-in-gitlab

It's a bit annoying, but we can automate adding folks to groups at some point.

oh ok, it's good that the docs tell the truth, makes sense that it didn't work that time because I wasn't in a group at the time.

I'm still confused. I'm a 'reporter' member of https://lab.civicrm.org/extensions/stripe/ where I just spent 2 hours on a MR, but there's no autocomplete on typing /spend - so I assume that won't work.

I looked a bit into this but could not find a good solution.

On merge-requests: It seems that developers/maintainers can /spend on an MR, but reporters cannot.

It's not as convenient, but meanwhile you can use the import UI:
https://civicrm.org/civicrm/timetrack/import#/import

Ex: 9:00+2h civi/dev extensions/stripe!50

(The comment itself is only a comment, this information does not get pushed back to Gitlab, but it could be useful later on for generating reports)

mentioned in merge request extensions/stripe!50 (closed)

added 15m of time spent at 2019-07-22

changed due date to August 15, 2019

assigned to @josh and unassigned @bgm

closed

mentioned in issue #32 (closed)

Using Gitlab to replace the Contributor log

Child items 0

Activity