The contributor log migrated to Gitlab on 15 August 2019. Some stats on its uptake can be found here. This issue is open to discuss how to improve the contributor log (i.e. how contributions are recorded, what contributions should be recorded, etc.), as well as how we recognize contributors. Example suggestions:
Kill it altogether!
Have a separate list for contributors and for financial supporters
Increase the value of contributions to have a greater impact on the current listing
@josh - responding to your observations about time recording for Barcelona: it would help if we had some agreement around what counts. At one extreme it's all the hours from leaving home to getting back - those hours all relate to the summit & sprint. More conservatively, it's just the hours in organised sessions and actual coding/documenting although lots of discussions about Civi continue over beer. Meals can be pretty much 'working lunches'. What about community day?
We could disappear down a rabbit-warren of detail - that's not the intention but a basic common understanding might encourage some (well, me!) to log something for the significant time involved.
I like the idea of recording contributions in principle. I think it can help people understand the work that goes in to creating the software. In practice it's not so easy to do and can be quite time-consuming to measure and track.
I've tried recording time in GitLab, but was unable to get it to work. I think that this might be because I don't have the correct role here but it's not clear how I get the correct role and in the end I just gave up. This is a bit of a barrier to tracking contributions from new contributors.
This is a permission thing for sure. In order to log time, you have to be a member of the group or project. I've added you as a member of the community group.
Thanks Josh. I think my point still stands that this is still a bit of a barrier for new contributors. I don't have any suggestions for how this could be improved but wanted to flag it as an issue. It may partially explain the low uptake.
Add a new time log category, civi/ext - CiviCRM extension development. As a lot of work goes into this area and using civi/dev as a general category hides where effort is going.
Anyone with a gitlab account should be able to log time on any project. There's been a few times I have observed where time cannot be logged due to permission of something else related to that project, not being a member. This is a barrier to time recording.
With more data flowing in then you can start doing some nice dataviz reports on civicrm.org and even in the CiviCRM newsletter. The CiviCRM core team can also better understand where contributions are going and assist in those areas.
Sound like sensible suggestions to me. I like number 3 in particular as this has certainly been a barrier for me. Is there a reason why we shouldn't allow any GitLab member the ability to log time?
I added a quick test for suggestion (1), since Gitlab has a feature for that:
The banner currently has an expiry time of 2020-12-31 and is easy to update from the admin interface
I see (2) is done.
Suggestion (3) is not possible, unfortunately. For many groups, you can join once and not have to worry about it (dev, extensions, infrastructure, documentation), but some other groups such as marketing and community usually have per-project membership.
Since I already have a time tracker, and I already had a script that output various reports on a monthly basis, I modified it to output my pro-bono entries in the correct format. I try to add time directly on to Gitlab tickets where I can, but any I can't, I import. Happy to share the script, but unless someone uses Invoiceninja and Pentaho Kettle already, it's probably not much use.
The current system works for me. I don't have many changes to suggest, and agree that $20 of ranking per hour makes more sense than $10.
I don't support separating the financial/support lists. Having a single list is of greater benefit to evaluators of CiviCRM; I appreciate that there is a way to get on the list solely through community effort.
For @cividesk, the feedback is very similar to @JonGold: system mostly works as is, we have our own time tracking and export/convert/import from the bulk form (so plan on a similar form in the new D8 website).
Areas of improvement:
Once entered, it seems our time logs are aggregated in pretty large chunks (ie. July through December), and we have no way of knowing what is included in the aggregate. We would rather like to see our time logs as entered (ie. one time log per bulk import), with all details entered in the import tool, in order to facilitate our accounting/verification. I do not know how the aggregate works for people that track time through GitLab, but it would seem sensible to aggregate no longer than once a month, and also provide all the details of their individual logs in this aggregate.
This is the data for September-December 2019. (I removed the data for the CT, because it's not known public data, but the rest is considered to be public)
Admittedly, we can argue that there are few people using it because it was hard to use. And avoid focus on the fact that some people use it heavily, that's great (they are often aggregate punches from many people at a shop).
I want to re-iterate that currently there is no code that is updating the financial data in CiviCRM for the time-contribution. We have to rewrite the code it and maintain it. I don't mind doing it, but I would like a clear confirmation that this is really what we want.
Option A (status quo):
Rank contributors based on a combination of their financial contributions and log of contributions not paid by their clients.
Attribute badges based on the number of hours contributed.
Option B:
Rank contributors based on their total financial contributions (partner fees, MIH)
Attribute a single (no tiers) contributor badge on request, based on certain criteria to be determined. Because sometimes a contribution might not have a significant number of hours and still be really important for us, and because we may want to promote exactly how people get involved (WGs, PR activity, marketing/events, extension dev maintenance, others).
Emoji-feedback welcome. If you have strong opinions about an option C that you think might have consensus, please feel free.
I would just like to point out that contributions accounted under my name should really be labelled 'Cividesk' as these group contributions from all our employees, with Yashodha and Sushant making the bulk of these. They are exported from our time management, and imported through the c.o Drupal form, hence not attributed personally.
Let me elaborate on option "b". There are a lot of problems with the way tracking is currently done, and many people simply don't do it as a result. One of the stickest problems is around valuing contributions... how much/little, and how to determine what is a contribution vs. what isn't. One can easily argue that everything is a contribution because, at the end of the day, everything benefits the project in some way.
One might say that the current process is focusing too heavily on valuing the contribution and not the contributor.
The idea behind option "b" is simple. Award the contributor badge to those that are clearly contributing, display them on the list (if they're contributors but not partners), but don't let the "value" of the contribution get in the way of celebrating the contributor. Instead of asking for tedious time tracking:
allow for nominations (for example, @JonGold periodically forwards us names of people that are active and encourages outreach)
allow for merit based award of the badge (somebody shows up with a cool new open source mobile app out of the blue and "dang, these guys are contributing!")
do a better job of promoting, highlighting, etc. the contributor (there are lots of contributors that simply aren't going to take the time to log their hours or promote themselves/their work... instead of saying "record your time or you don't get recognized", perhaps we should do more direct outreach and promotion).
Obviously that last part requires more ongoing work, and the only way to do it (consistent with how we work) is via a team of people that do that sort of outreach.
The end result is basically the same... except that we're likely to capture more contributors, we remove the maintenance/management of tracking time, we remove the "value" associated with the sorting on the list, and we take a more personal approach to contributor engagement.
I'm nervous about 'b'; it seems arbitrary and based on a benevolent dictator model with the exception that the dictator here is those with the loudest voices in certain forums (e.g. matter most/lab); those with the most time to chat. Obviously there's a crossover here, but it's also a bit cliquey - might be harder for new people to get recognition.
I'm not a big agency with resources to spare to ensure my company is getting the recognition it deserves [and probably needs for marketing purposes]. As a person who spends most of their time alone in a shed working really hard to support the aims of the organisations I work with through tech, part of which includes CiviCRM, and who is trying (struggling?) to actively pull-my-own-weight in the community while still needing to keep things going and be a Dad, I think someone like me could easily get forgotten. Perhaps that's right, leave it to the big guys (often it's guys), but being forgotten about would make me feel not good enough and would basically do the opposite of encouraging me to contribute.
I'm not after sympathy or reassurance here, but just using a personal view to set out what I see as the dangers of option (b).
For me (a) seems fairer, although this might be because I don't care where I come in the rankings, but it means a lot to me to be listed (it's kinda like membership of a professional body - external palpable public validation). I suppose if I did care, I'd be questioning whether some normalisation factors should come into play (e.g. divide by FTE hours working on CiviCRM; turnover). That seems hideously complex though, so my vote goes to keeping things simple.
Thanks @rich for the feedback. Actually, I feel exactly opposite. I think it provides an option for the community to "give a pat on the back" to a contributor, especially the small ones that struggle as you've said. For example, of the 40+ people came to Barcelona, how many 1) logged hours and 2) are listed on the site? Most are not, and yet it would be pretty easy for any one of us to 'nominate' them.
I understand the risks, and I'm not sold on the idea, but I actually feel like it could be positive approach and am trying to focus on the upsides rather than the downsides.
I think, realistically, we're seeing some of the downsides of the current approach:
imbalance in who is listed and who isn't
private lobbying to promote what a person feels is a contribution or should be
a challenge to properly value contributions and manage the entire process
Again, I'm not dead set on "b", I just want to be realistic in how it's presented, at least relative to the current process.
Thanks @josh, I'm aware you bring a lot of experience in managing this process that I have no idea about!
I'm not sure how nominations would work, whether they'd be easy, how you'd find out about it, to whom it would occur to nominate who (whom?! I dunno!), how you'd stop someone lobbying, how you'd deal with people/orgs who felt their contributions had not been fairly judged.
But I'm up for trying it out if you and others think it's going to make things better/clearer/fairer :-)
Personally I see it as consolidating contributor engagement. i.e. it goes beyond a simple count of hours.
And it's also an opportunity with regards to Working Groups (WGs).
Currently the way (I think) it really works, is people like Jon, Eileen, and a few others, tend to keep an eye on new contributors, or on the progress or some contributors, and promote engagement (promote their work, encourage X to contact Y, spend more time doing review/mentoring, add to the contributor listing, nudge / strongly encourage to participate in events, etc).
So I think WGs should be nominating contributors, and promoting those contributions.
(and, sure, some WGs are more informal, but many are well organized, and I think it's a good growth structure)
and yep, I'm spinning 180 on supporting the contributor log. I think we tried two iterations and it failed.
My initial comment was written as a CiviCRM provider, and I said the system works for me. Now I'll answer from a community management perspective.
First, we need to change the question. Instead of, "How should we change the listing?" let's ask, "What goals are we trying to achieve by changing contributor recognition?"
Second, there's a community of OSS community managers out there who think about this, and we need to be engaging with them. E.g. the All Contributors project is an inspiration here, as is The Art of Community.
Without knowing what our goals are, it feels premature to give a counter-proposal, but here goes:
My goal is to create a ladder of engagement. We want to get more first-time contributors, we want them to become ongoing contributors, and we want ongoing contributors to give lots of time and money.
The current partner list does (in my opinion) a good job of meeting the needs of the last group. It's no accident that Nicolas, Rich and I all support option A above. I propose keeping it as-is.
The list does NOT meet the needs of encouraging first-time contributors. Let's make CONTRIBUTORS.md more akin to the All Contributors project. We talk about a separate "contributors list" like we don't already have one - but we do. Increasing its visibility and recognizing different kinds of contributions would, I think, meet the needs @bgm mentions, and formally takes the pressure off the partner list to meet this need (which I agree it doesn't).
I'm not addressing top contributors (e.g. BCN attendees) who didn't log hours. They can speak for themselves, and they're not saying the system doesn't work (but they should chime in if I'm wrong!). I have heard them say they don't care enough to log time, and there's nothing wrong with that. They're still recognized in CONTRIBUTORS.md and release notes (recognizing current contributors in release notes is great IMO, and something we haven't discussed here yet).
I understand that the recent discussion about how to log London CiviCamp is probably driving this conversation more than we're saying. I don't think that's proof the current system doesn't work; any system we discuss here involves spending resources on its maintenance. IMO the solution is to get the EC up and running and empower them to make rulings on these issues - shifting the resources needed off the CT.
As one practical note - one person interviewed in The Art of Community is Richard Esguerra. Richard is part of the Civi community. He was Development Director at the EFF and works for Giant Rabbit now - a former top contributor to Civi who we should be asking to re-engage :) I'd love for @josh to ask Richard/Giant Rabbit to help talk about these issues with us.
Just as a comment on the mechanics of capturing contributions. Couldn't you automate some basic contributions metrics by doing things like:
For every comment posted on gitlab, github, stack exchange and mattermost, record a 5 minute contribution for the author
For every issue posted on gitlab, record a 15 minute contribution for the author
For every PR posted on github, record a 1 hour contribution for the author
And so on...
The fact that people would also log hours and potentially double-up and that some activities are more or less than the automatically logged metric doesn't really matter. It's imperfect but you would easily be able to identify regular contributors this way. It gives a reporting mechanism.
Then the other half of the discussion (most of this thread) is: how do you reward contributors? Because recognising who they actually are is something that can be done.
I think it would be a very interesting exercise just in terms of general project analytics.
Counting these actions seems like a good idea to measure community engagement, identify new contributors, etc.
But auto-assigning a time contribution for each action seems quite a stretch ... the contributed hours log will then be so far-off that it will become completely useless and insignificant.
Consultants usually send a bill to their clients every month by summing-up the hours worked for each client. The process should be exactly the same for contributed hours - CiviCRM is just a client like any other. If partners are not doing it, it is NOT because it is complicated, difficult or time consuming. It is because they do not see the value in doing it - it is simply not worth their time to log, and then report, these hours.
If the CT sees value in getting ACCURATE contributed hours for the project, then they should place the right incentives on partners so they are reporting these.
We have a ton of data, but what it is providing? We know where to focus efforts.
I'm reluctant to invest more in instant-technical-debt. It's a lot of discussion for something that provides little variation on the partner listing. I still don't see the value.
@bgm are you saying you disagree with the summary of this issue? "Improve the process of capturing and recognizing contributions and contributors, aka the contributor log"
"ton of data" - what data? Can you provide examples or clarify what you mean here?
Until Josh recently sent his "log your contribution hours" email, we pretty much had never logged any contribution time at all. Yet, we have been actively contributing to CiviCRM since 2014 (possibly earlier).
So in terms of logged time data, this would not have been reflected at all until recently. And even then, this is only a small portion of our contributions to the CiviCRM project.
We log all worked time, have years of work records from multiple team members and we know exactly how many hours we have contributed to CiviCRM - I know how much CiviCRM costs (
,
$).
I am OK with sharing that data with CiviCRM as long at is provides some form of benefit (to both parties).
I thought this discussion (as per the summary) was about a) making it easier to log contributions and b) recognizing those contributions (providing a benefit).
@justinfreeman In an earlier comment, I said that I thought that various stakeholders had different/multiple motivations in revamping the contributor log. I think the difference in goals is what's causing disagreement here.
If I'm understanding you correctly, it sounds like your interest in this topic is tied to how the community gives recognition to contributions. Is that correct?
I think that resistance to a revamp - by you, me, Nicolas, etc. - is tied to the recognition/reward aspect. But if CT has an additional motivation of encouraging newbie retention, I see why changes are in order. But not at the cost of what already exists.
I think keeping the partner listing as-is (money + time, both measured concretely) but giving a greater role to a contributor list (non-monetary, with "contribution" being subjective) can achieve both those goals.
Finally, I understand why having an automatic metric isn't desirable here. It adds complexity for folks in our position (do we subtract an hour from every internal timeslip I log on a PR?). If the metric we want to capture is number of PRs/Gitlab tickets/etc. opened, we can measure that already. And measurement is only useful if we have a goal, and the resources to achieve the goal.
@justinfreeman Could you elaborate on the benefits you would expect in order to be sharing your contributed hours? That could be good suggestions for the CT in order to increase participation/usage of this tool.
@justinfreeman@bgm re: metrics, please see https://stats.civicrm.org website. It has many data points that could be used for decision-making, including on Jira issues and GitHub PRs. Those could have been used to identify new contributors, sustained contributors, rank contributors every way you can imagine, etc. Yet AFAIK they have not, and when the transition to GitLab took place, nobody asked me to gather these new metrics.
My point is: yes, we already have plenty of metrics, but they are vastly under-utilized. So ... why collect new ones unless a) we already know how they will be used, and b) we have a commitment that they will be.
And finally, an offer: if you define how we could use the metric you've proposed (# comments, issues and PRs) and commit to using these in whatever proces makes sense, then I will commit to writing the collection, archiving and graphing for these metrics as I have for all others on the stats website.
I just want to mention that I really appreciate the time everyone is putting into this issue. I realize I'm going against the consensus, but I do see a few different perspective in this thread, and not a clear path forward. We tend to stick to the status quo when we don't fully agree, but in this case it's not possible because it requires a fair amount of work to keep it going.
Fun fact: the code had been broken for a long time. It was using sumfields with a custom hook, and the SQL trigger was missing. The data was not making any sense, when I pointed it out I was told "it's fine", and it was not. It was broken for a very long time.
I also wasted 2-3 stressful hours last night, as I thought I was doing a routing setting save, which ended up deleting all sumfields settings last night, therefore breaking all the smartgroups, and the partner listing. It's still pretty broken (sorting), but at least it's not a fatal error. (infra/ops#933 (closed)) - (it's not the fault of sumfields, but I don't quite understand what happened)
Nicolas: So ... why collect new ones unless a) we already know how they will be used, and b) we have a commitment that they will be. [...] And finally, an offer: [...]
In general I think we have a problem with stats, because they tend to contradict each other. Numbers are great, but they need analysis, and they need engagement. We are a small team and we have a lot of technical debt already. Pingbacks are another example. We removed them not because fewer people use them, but other metrics show a 5-10% increase year-on-year.
edit: clarification: we do not display/promote the pingback data as much. We still collect it.
As said before, we already know where we have to engage. We need to do less coding, more engaging. :)
Jon: "I think that resistance to a revamp - by you, me, Nicolas, etc. - is tied to the recognition/reward aspect."
Currently the system rewards only 3-4 shops (including mine). It does not reward the rest because it barely registers. We are assuming that everyone will start reporting time. I'm a bit skeptical. Maybe a few bigger/structured shops will do it. Others will feel pressured to justify numbers. I think it's become a weird civicrm-only thing. Nobody does this. Explaining this to each new partner or each new contributor will be weird.
To compensate, I think we should 'reward' in different ways (discussed above).
Justin: "are you saying you disagree with the summary of this issue? "Improve the process of capturing and recognizing contributions and contributors, aka the contributor log""
Yep, as commented above, the more I dig into this, the less I support it.
We have had issues with that log for a long time. Either folks reporting hard-to-verify data, or hard-to-use data. We tried tweaking how it's worked. I don't think we found something that works.
Before the contributor log, we also had the "top contributor charts" (which ranked based on other metrics) - it was very shortlived. The purpose was great, but long-time contributors were often not in it, so they felt it was unjust towards them.
The Gitlab idea was mine, and it was a bad idea. I am already getting way too often pings about "why can't I /spend in this project", and there's no easy fix. We're a small community right now, and if we grow, this won't scale either. - The initial objective of Gitlab spending was to help the CT track their time. That part is a success
tl;dr: We have invested a lot of time into this. Lots of great ideas, good intentions. Little results.
"ton of data" - what data? Can you provide examples or clarify what you mean here?
Gitlab activity, mattermost presence, stack exchange, PR review, Working Group activity, civicrm.org data (site registrations, feedback on partners), etc. No matter the data structure, it still needs analysis, and mostly, it needs to be useful for something.
"Until Josh recently sent his "log your contribution hours" email, we pretty much had never logged any contribution time at all. Yet, we have been actively contributing to CiviCRM since 2014 (possibly earlier). We log all worked time, have years of work records from multiple team members and we know exactly how many hours we have contributed to CiviCRM - I know how much CiviCRM costs (
,
$)."
Yep, many folks in that situation.
Do you know exactly how much was paid by clients, directly or indirectly? (this is not meant to be snarky - as a shop, I find it hard to track that exactly when it's usually driven by client work. I just see it as a cost of doing business.)
That said, currently the system only took into account data from the past 12 months. At some point we need to draw the line to what's relevant data for "today". I have been doing civicrm for 13 years.
"I am OK with sharing that data with CiviCRM as long at is provides some form of benefit (to both parties)."
Please don't take this the wrong way, I'm asking in the most naive way: what's the benefit for CiviCRM? I would much prefer promote your extensions, promote the work you have done, organize webinars, etc.
Again - we have very limited resources. Were they infinite, I would love to explore our data more. I just don't think it's the best priority right now.
@bgm's arguments partially sway me. I would prefer that logging time helps ranking, but it doesn't affect how much time I would spend. Ranking by time has a cost to the CT.
I'm partially unswayed. Partner listings are huge drivers of business. It's a valuable resource the core team controls and uses to encourage time contributions. This resource shouldn't go unused. @bgm isn't arguing against the idea; he's arguing it takes CT resources and people aren't reporting. Maybe rankings could be influenced by pre-existing metrics?
Here are some brainstorming thoughts:
If my listing was ranked (or displayed) by my extension directory count, I would 100% list more of my extensions. I don't like this particular idea because it could potentially limit cooperation or cause turf wars.
"Case study count" is perhaps a better choice?
Github metrics?
I personally vote for SE points
That said - if this is a "phase 2", I can live with that.
Interesting thoughts when taking a step back and reconsidering:
A principal objective of the Core Team is to encourage more contributions to the project. Having the partner listing ranked by a combination of money and time contributed should have pushed to more contributions, either monetary or time wise. Considering the time aspect, the metric designed was through the time logs.
Yet ... it does not seem to have worked as so few partners have logged their time.
But ... there is a healthy pool of large and sustained contributors to the project.
So ... partners are contributing, but are not being enticed by the partner's listing benefit.
why are partner's contributing now? what drives/motivates them?
which perks/benefits/recognition would have them contribute more?
I suspect the answer to the second question will be varied: @JonGold and I value the partner listing benefit, some others will value other kind of promotion and/or recognition and/or benefits.
So ... let's keep the partner listing benefit, but also add additional options (congratulatory email from Josh, blog post or newsletter article, contributor of the month/year award, sponsored trips to conferences, discount on partner fees, ...).
Now ... if the partner listing benefit costs money to maintain, let's find a CHEAPER way to rank partners based on their time contributions ... but ... that's already what we have with the Contributor badge level. There already are criteria in place for each level, so let's just put a $ value to each (ie. empowering contributor = $500), and rank the partner listing based on $ contributed + $ equivalent partner level.
With the above I would support retiring the time logs altogether. Note: the above also includes 'other types of recognition for our contributors' ... ;-)
@josh@bgm The 'Find an expert' page on c.o seems to be completely re-organized, and partner badges are now different (ie. Gold, Silver, Bronze). Can you clarify both the new partner levels and the ordering on the providers directory? Thanks.
We indicated previously that we were considering changing the tier names and confirmed this with partners a few days ago. We are in the process of switching over the site. We rolled out the new badges a few days ago and have similar badges ready for contributors. However, this thread should be resolved before doing so.
The listing was recently busted and is currently showing partners only in random sorting. We are aware of this and are working on a revision.
The announcement re: badges is here. Regarding the listing, the partner survey in 2019 favored the current sorting model, ie. by "total giving". I believe that will be recreated, however we need to resolve whether we're tracking/accounting for contributions or not.
In this thread, I see some discussion around both accounting for individual contributions as well as taking a more qualitative approach to recognizing contributors. In the event that the latter approach triumphs, the listing will include contributors, however it will likely be sorted by financial support.
Wish I'd read this thread before spending that last few hours sifting our timelogs and submitting for the first time if you guys are going to drop the idea... ♂️oh well! Can I submit a timelog for the time to submit timelogs?!
I've only had a brief read of the above and I don't want to detract from the conversation too much; whatever you guys decide will be what you decide as this is obviously a complex area and really Compucorp's needs aren't going to be your primary concern here.
From our perspective we just want to make sure that we have paid our dues, as we have done since the beginning of the partnership programme, and be able to demonstrate that we have and will continue to do enough for the community/core team to consider that we are a key contributor and to have the badge to show for that and to be high enough on the listings that when people are looking for a team in the UK for a project we will be invited to pitch!
Just a couple of data points for you:
I don't think the https://civicrm.org/civicrm/timetrack/import#/import form is too much of an ask for larger partners to import their data once every few months (once you've worked out how it works!). It works very nicely @bgm thanks for all the work on this! I only just got around to doing it as the last few months have been crazy busy, but we all have timesheet systems so I'm sure that would be fine. I do understand that this is a burden however for smaller orgs who maybe don't track time in the same way.
Let's not assume that it's "easier" for big shops than it is for "little shops" to contribute time. There seems to be some assumption that by being bigger, it automatically means that you have more spare time, but in reality what we're super stretched as much as the next individual or team in the community; sometimes more as it tends to be the big projects that tend to run over in the worst ways and we need to pay salaries and meet deadlines...
That said I am a bit turned off by the whole idea of tracking "contributor hours" and here is why:
Basically it's all about what is considered a contribution... So most "partners" are paid in some way for their services around CiviCRM. But what we are talking about being a valid contribution is time that was not paid for by a client. The problem being here is that I think that line is very blurry. For individuals perhaps this is easy to look at - I did this task, or commented on this git lab and hence made a contribution.
But for us, we've done some big builds on extensions that we're not in themselves paid for by clients, which we/I hope will really push CiviCRM along. These were done as there was a big enough project opportunity to make them worthwhile so we built them and continue to develop them as we know they are essential for us being able to compete with Salesforce and MS dynamics providers (shoreditch, new cases, membership extras, new awards). We've spent thousands of hours on these to be frank, but they get us to the table on the biggest projects. On the other hand, some extensions we maintain because they are used by our clients but they don't pay for them directly (i.e. Gift aid / Pivot tables / Prospects / CiviBooking) so we maintain them. We always put everything we make out for people to use as I know everyone else on this thread does also.
At the end of the day if you make a living from working with CiviCRM by definition all of your time is paid for by the clients! Just because you chose to allocate some of it onto things that make the product and tools better (perhaps with the goal being so you can have more happy clients!) doesn't mean that it wasn't funded really by clients. In fact unless the partner is making a loss I'm not sure we can call anything a contribution (perhaps!).
I know this isn't the most helpful of comments but I just want to highlight that this is a really vague area - especially if we are going to start ranking based on these hours.
ps. Where can we actually see our own or others contributor hours listed?
Thanks @jamienovick1 for the feedback. Your comment about what constitutes a contribution is a "blurry line" is accurate in my view. I drafted this (which you may not have seen) for precisely this reason. Some contributions are very clear, whereas others are not. As we try to value them, we invariably increase our management costs negotiating what is and what isn't a contribution, tracking them, etc. As I've stepped back from it, it seems to me that taking the approach places too much emphasis on the contribution (its value) and not on the contributor. My guess is that most contributors actually want some recognition and appreciation, not an onerous mgmt process to rank contributions against one another.
In any case, thanks for the feedback and thank you for your contributions to CiviCRM. You have earned yourself a contributor badge. Good job. ;)
ps. Where can we actually see our own or others contributor hours listed?
@jamienovick1 the "my logged contributions" link when you log into Drupal brings you to this report: https://civicrm.org/civicrm/report/instance/81
It defaults to filtering just your own contributions, but you can change the Current Contact filter to "any" and see everyone's time. (Helps if you enable the Contact column.)
ps: Only certain admin roles can access Report Criteria. Otherwise it should not be possible to view time for other people. The CT uses this as their primary time tracker, so it's a bit sensitive.
Gotcha. While I understand you may not want to expose entries that were recorded under the presumption they were private, @bgm I do think it would be worth making everyone's entries public (or at least public to partners, contributors, etc. who can record hours). I don't imagine you're up to anything nefarious, and I think that kind of transparency will help everyone have a better grasp on all the work needed to keep CiviCRM going.
When I first looked at this time recording report back in December/January, it very much looked like we had recorded more time on the CiviCRM project than CT. So was not sure if CT was using time recording at all.
I want to make a full-throated defense of tracking hours. I started as a skeptic. We don't always track all hours, but we've made it work by not trying to record hours bit-by-bit in GitLab. We just record CiviCRM hours in our own system alongside project hours and export at the end of the month. (I will note it was much easier before last year's changes.)
There are three main principles behind why I support recording hours:
Some contributions are higher-profile than others. The amount of time needed for some contributions is higher than others. Relying solely upon thank-yous and contributor badges devalues the hours that someone might spend mentoring new developers, reviewing pull requests, or planning an event. I've said it would be good to have visible acknowledgements for defined roles, but that doesn't replace the monetary value of everyone's time, especially doing things behind the scenes.
We should stick with a single list of shops. Having separate "hosting" and "service provider" lists was a mistake, and so would separate lists for contributors vs. partners. If there's a single list, the ordering should reflect contributions, so it makes sense to value time contributions on the same scale as monetary ones.
Time is money. We all charge for our time, and those of us with employees pay them for theirs. Contributing time to the project is giving up time that we could be spending on client work, on vacation, or building our businesses. Sure, someone could spend an hour on something useless, but we need to give each other the respect of assuming that we each contribute to the project in the most valuable way we know how.
Some contributions are higher-profile than others. Yes
We should stick with a single list of shops. I disagree with this point. A single list has a single ordering, which does not make sense when you shove three completely different categories into it: Partners (shops), Sponsors and Contributors.
I understand the different categories, but I'm thinking from a user's perspective that it would be confusing to see three overlapping lists.
A separate list of individual contributors (disaggregated from their employers) would have a distinct purpose, but we do have that in the CONTRIBUTORS.txt, GitLab and GitHub, and the release notes. We could just highlight those more.
And ultimately, I'd expect a list of partners to be weighted by cash and time contributions, so the other lists are kind of a separate issue.
I understand the different categories, but I'm thinking from a user's perspective that it would be confusing to see three overlapping lists.
Each list has a distinct purpose: Partners, Sponsors and Contributors. The list should state the purpose clearly.
Then there is no confusion about the purpose of each list. And the concept of there being "overlap confusion" does not apply, since these lists are distinct. I think you're applying the current "single list" thinking to this suggestion.
I mean, if we really want to keep this single list mentality, why don't we throw all CiviCRM sites (end users) into the list as well? Surely they have some practical CiviCRM experience and therefore by the current loose definition are "Experts". They support CiviCRM by using the product and will undoubtedly also financially support the product by employing people who either directly or indirectly contribute to the project. But no, we don't want to do this because the single list would then become huge and non-sensical. Which is not far off from what we have now.
Anyway, I'm going to stop banging on about this... I support the original issue description which says: "Have a separate list for contributors and for financial supporters" - Yes, I agree.
JMA is not consistent in logging the time we contribute to the project but do not bill to clients. Periodically, we'll post some hours. We take pride in being major contributors, and try to be good community members in terms of maintaining extensions for free, contributing to QA of PRs, commenting on gitlab issues, working on infrastructural topics like keeping core up with MySQL and PHP versions, doing a bit of moderation of stackexchange, etc. We're forever feeling that we're not keeping up with all the things that we'd like to in terms of QA'ing more PRs, responding more quickly to extension issues, responding to @mentions on various threads, etc.
We'd like the listing to have an option to show big contributors. We also liked it when the sort for people looking to hire experts/services providers defaulted to a way that incorporated our contributions, both financial and time.
We're willing to do the necessary to maintain our partnership and ranking in terms of the overhead of producing case studies and logging time (periodically).
We could spend days on these debates and still have more to say. We don't feel like it is worth it for us to get fussed about this as we are so busy the higher rankings won't make a big difference.
@JoeMurray yes, a minimum number of contributed hours should be required for each contributor level, and they should be accounted for through the existing process, but beyond these it's up to the partner to decide if they want to log additional time or not - some will see the benefit, some won't, it's fine either way.
Thanks everyone for the feedback. I want to state some observations based on the discussion so far. I'm not expressing my opinion. Just observations, in no particular order.
The title of this issue "improve the process of capturing and recognizing contributions and contributors", yet we always seem to gravitate to the "list".
"Time is money" is a nice statement and it's easy to make. However, it does not answer some of the complexities of actually accounting for contributions that we have already experienced. I wrote this issue to highlight a few of these.
These discussions can get long and frustrating, and we can start to simplify our statements. We should be careful not to state opinions as facts.
There are a lot of contributors not participating in this discussion. Why is that?
Some other points to make since I'm writing:
We are changing the "technology partner" program and can remove them from the "list". They'll be recognized separately.
Historically, valuing contributions has been difficult for many reasons. Some that we don't often talk about are 1) the private lobbying that's done around what should and should not be counted and 2) the efforts to game contributions (yes, this does happen). These increase the mgmt costs.
Regarding the "time is money" statement and sustainability#19 (closed), I really don't think that any of the complexities listed there are all that difficult to resolve, except possibly the shop with a client who pays a flat fee for unlimited bug fixes. Even there, the question really is one of whose contribution is it (much like the one shop paying the other to fix things), and that's between the shop and the client.
There are a lot of contributors not participating in this discussion. Why is that?
I think it's because the discussion is split among a bunch of tickets and the consequences haven't been highlighted for everyone.
Historically, valuing contributions has been difficult for many reasons. Some that we don't often talk about are 1) the private lobbying that's done around what should and should not be counted and 2) the efforts to game contributions (yes, this does happen). These increase the mgmt costs.
Both of these are news to me. I really think transparency might be the solution to this:
Make the time contributions (semi-) public so that everyone, or at least all contributors, can see each other's claimed time contributions.
Insist that any discussion about what should and should not be counted be in public GitLab tickets.
These are also things that really should be handled by the Community Council (nominations opening soon), so that body can take some of the burden off of the Core Team in terms of collecting feedback and setting rules about this.
I also agree that these can be resolved, however I believe they're more complex than we realize. We run the risk of over-engineering something at the expense of what we should be doing; celebrating contributors.
My point about "why aren't more contributors here" is more broad. We rolled out the contributor log to GL and very very few people used it. So, beyond this specific ticket, why is there very little participation? I mean, there's plenty of contributing going on, but not much appetite for this sort of tracking and management. We could take the approach of "well, if you report then cool, if not, then that's your choice" (which is kinda what we've done up to this point), but I'm concerned that we're missing out on the real opportunity of properly recognizing contributors.
We did increase transparency by shifting to GL, and that has largely worked. Except that use of time tracking on GL has fallen off (from the previous contributor log).
I for one welcome the community council, in some form, but I'd like to resolve this sooner rather than later. This isn't a burden to the core team, and because there is some overlap potentially with the partner listing, I'd prefer to keep it on our plate. We've been collecting feedback on the various tickets and in one on one discussions, and I believe a plan is taking shape.
On the point of "how we recognize contributors", I was actually a bit surprised to see no mention of top contributors or significant contributors in the Annual Report, https://civicrm.org/annual-report
I recognise that those who have contributed financially do get a prominent mention (eg. ESR and Spark), surely those other contributors should also get a mention as well?
Thanks everyone for the feedback here and on related issues. We plan to digest this and come back with a revised approach to capturing and recognizing contributor support.
I know tis is a bit late in the day, and that the thread is pretty much over, but I've only just come accross it, and feel the urge to mention that I think that it could add to the conversation to mention that I think there are actually 3 branches here, not two. They are the Three T's.
TTT
Time
Talent
Treasure
Rich is at home being a dad, so is Treasure (cash) poor, and Time poor - but we all know that he has a great deal of Talent to bring to the party, and that's about his investment into the project. (1 hour of his on fixing something is probably worth 4 days of mine!).
I'm not sure what pulls me to mentioning it, but as mentioned above - a small amount of time from someone with the Talent can be extremely beneficial, but goes unrecognised if we just measure time.
I know this could be a spanner in the works, and is probably too late to make a difference to the way forward atm, but I think it's a good thing to consider and bear in mind when it comes to recognition of what goes into Civi from the community.