Change how sort ordering works on /drupal-services

I knew there was a reason I'm in the middle of starting a company that starts with 'A' :)

But seriously, this really is an argument for either a random seed, some kind of rotation or if you're feeling profity, charge to be on the front page. This only applies to the front page, not all the subsequent ones.

I'd suggest a rating system but that is going to bias heavily to either big companies with lots of customers or unscrupulous small ones that are willing to fake ratings.

I agree that the current listing sort for both All Providers and featured Providers gives the advantage to the "A" organizations. There has been some discussion in the issue queues and on IRC about format for the Marketplace listings about random order, ability to search the listings, etc. I'm hoping some of these changes can be incorporated in the D7 update.

Definitely wouldn't want a rating system that would affect sort order, though.

There are various possibilities of improvement for the Marketplace, once governance process is complete and we have Drupal.org working groups in place, we should definitely have conversations about them.

Something as simple as just randomizing order on the Drupal Services landing page could be done before governances structure is ready. However right now we are deep in the Drupal.org upgrade to Drupal 7. Because of that we try not to make any changes to the D6 site, each one of them takes away the time we could be spending on the upgrade and gives us a little more stuff to upgrade. If you'd like to work on randomizing the order on that page on D7 version, we can create a development site on our server for you to work on.

Sorry Nicholas, this fell of my radar. Going to free up some space on the dev server now and create that site.
In the mean time please see instructions on working on our server: http://drupal.org/node/1018084. Particularly you need to do step 1 - open an issue to get your SSH key added.

There are definitely more D7 issues where any help will be much appreciated. Let's talk about those in your SSH keys issue or on IRC for not to go completely off topic here. :) Thanks!

Dev site should be ready in about 2 hours. Url will be http://marketplace-drupal_7.redesign.devdrupal.org/

So as I said in #2179373: Randomize Drupal Shops in Marketplace I think it's a matter of changing this view all/modules/drupalorg/features/drupalorg_marketplace/drupalorg_marketplace.views_default.inc

/* Sort criterion: Global: Random */
$handler->display->display_options['sorts']['random']['id'] = 'random';
$handler->display->display_options['sorts']['random']['table'] = 'views';
$handler->display->display_options['sorts']['random']['field'] = 'random';

But then the view needs to be re-loaded...

Would be great to see some movement on this topic (as someone who is lower down the alphabet in the Marketplace).

+1 very much.

Does this need some sandbox testing first? Doesn't look like it.

Ok, here's a patch and a demo of them in a sandbox:
https://search_api-drupal.redesign.devdrupal.org/drupal-services
https://search_api-drupal.redesign.devdrupal.org/training

This is more fair for companies lower in the alphabet.

Moving to this issue queue so we can hopefully get it implemented soon.

Paged Views can't be randomly sorted. If you click next, there are totally new random organizations. Maybe even duplicates of what was on the first page. If you click back to the first page, they will be random again. You can't re-find anything.

Thanks @drumm - that's fair.

However, there are other options to consider.

It could be ordered asc or desc - perhaps based on whether the day of the week is even or odd.

Perhaps the sort order could be based on some other element some of the time.

However, the simplest thing would be to just have the landing pages have random content:
https://drupal.org/drupal-services
https://drupal.org/drupal-services/featured/Theming

But have a View all link that just goes to the alphabetical listing. Alternately we offer a few ways to sort based on alphabet, proximity, company size.....

This will take a bit more to craft up, but not much.

As suggested in this issue, if random order doesn't work, could we have one or two randomly selected organizations appear at the top of the view?

We've used this module on a few sites: https://drupal.org/project/views_random_seed and it allows you to sort the view but in a semi-predictable way.
So, for example the ordering of the listings could be random, and change every day.

Sounds like a viable option.

Interesting view on this from @dries keynote in Amsterdam
http://youtu.be/4NN5EM4CYVE?t=44m59s

Now that we have issue credits recorded in Drupal.org fields, and this is directly related to the current community focus on Drupal 8, it is a good way to order the results.

So @drumm - we could soon see sorting based on the participation in the issue queue?

That would be nice!

Yes. This initial deployment is adding a field to store the credit sums, so they can be quickly and easily be used to sort Views. Other types of credit can be factored into the calculation in the future.

Leaving at needs work, since this doesn't make any public-facing changes yet.

This initial part is deployed. These numbers will currently be updated daily.

mysql> SELECT * FROM field_data_field_org_issue_credit_count;
+-------------+--------------+---------+-----------+-------------+----------+-------+------------------------------------+
| entity_type | bundle       | deleted | entity_id | revision_id | language | delta | field_org_issue_credit_count_value |
+-------------+--------------+---------+-----------+-------------+----------+-------+------------------------------------+
| node        | organization |       0 |   1121114 |     8801105 | und      |     0 |                                 50 |
| node        | organization |       0 |   1121120 |     8330589 | und      |     0 |                                  1 |
| node        | organization |       0 |   1121122 |     7442245 | und      |     0 |                                  2 |
| node        | organization |       0 |   1121166 |     8589558 | und      |     0 |                                  5 |
…

This has been deployed with some additional visual updates.

Looks great @drumm - thanks! I do hope it inspires more contributions.

I'm fine with moving away from alphabetical sorting. But currently there is a great chaos in the list. I see many companies without any obvious contributions higher in the lists above companies with lot's of contributions. And why we skipped the "featured Label" which is still in documentation (e.g. marketplace FAQ). This is a good check of real people about contributions in my opinion. And evaluating the companies was also a contribution of many people in the last months which is not visible anymore.
And as a part of a very small company I want to remember that contributions of a company should be compared to the sum of employes.

I sugest to add featured flag again to marketplace entries and also use this for sorting like the node sticky flag. Using only the the calculated issue credits is unfair against organizations which are contributing without code e.g. organizing drupalcamps. The "featured flag" is not only respecting this. It is recommended to contribute on more than code to get this flag.
Additional to my other comment where I suggested to calculate the value of contribution compared to the size of the organization I think the calculation time should be extended wider than 3 months. This I suggest because it's hard for small organizations with only a few members to push the issue credits all the time. But basically I like a calculation which respect the last time because there are many organizations which have contributed in the past and still looking active.

@drumm: You have related the commit for 'Merge "all" and "featured" service providers' to this issue. Is there another issue where this was discussed?

But currently there is a great chaos in the list. I see many companies without any obvious contributions higher in the lists above companies with lot's of contributions.

The current ordering is issue credits, Drupal Association membership, alphabetical.

And why we skipped the "featured Label" which is still in documentation

Part of this was simplifying the review process, which had nebulous requirements and waiting for manual review. I expect the calculations will expand to include more than issue credits in the future. And yes, the documentation needs an update.

You have related the commit for 'Merge "all" and "featured" service providers' to this issue. Is there another issue where this was discussed?

This was a bit of a scramble to implement as DrupalCon was starting. We discussed it internally at the Drupal Association.

The data for which organizations are featured or not remains in the DB, so if we do need to keep using that distinction, it is possible.

Additional to my other comment where I suggested to calculate the value of contribution compared to the size of the organization I think the calculation time should be extended wider than 3 months. This I suggest because it's hard for small organizations with only a few members to push the issue credits all the time.

3 months was chosen because that's how much data we had at the time issue credits were added to organization pages. It could be extended back to the launch time for attributing comments.

Adding to some of the notes that @drumm added, we are considering adding the following additional factors to sort characteristics:

• Camp sponsorships in the past 6 months as reported by camps: Currently the process relies on self-reported information. Camps can provide us with this information. Additionally, we may be able to track camp speakers and attendees and work this into user profiles.
• DrupalCon sponsorships in the past 6 months: We have this data.
• Case studies associated in the past year: We have this data in the form of a node reference, but we would need to figure out how to make it time based.
• Modules/Themes/Distributions sponsored as reported by the project maintainer: We have this data, but it might be duplicative to the issue credits.

We'll be taking a look at the possibility of dividing the issue credit count by employee count. In practice, I don't think we need this. It would arguably push Acquia lower on the list, but it wouldn't affect the rest of the listings that much. For example, MD Systems is number 2 on the list with only 18 employees. Further, pushing Acquia down the list seems like a penalty for their size and not their level of contribution. They support camps and Cons, they are supporting partners helping to fund Drupal.org, they support quite a few projects as well.

One thing that will likely help smaller shops that are further down the list will be better sector, services and location filtering. We are planning to release taxonomy pages for each of these vocabularies that will make it easier to highlight contributors that have a particular focus or location. So a company might be on page 8 of the complete list, but in the top 10 for a particular taxonomy page.

There are lots of great options for us to look at for sorting, so please give more feedback with your ideas. We will not be able to implement them all, but we can iterate on this a bit more.

Further, pushing Acquia down the list seems like a penalty for their size and not their level of contribution. They support camps and Cons, they are supporting partners helping to fund Drupal.org, they support quite a few projects as well.

I am not interested in pushing especially Acquia down in this list. But it was not my decision to make the issue contribution to the only sorting criteria. But this currently pushing many other organizations down in the list which are contributing more than others. That's what I am talking about.
It's amazing that such a small company like MD Systems get so much issues forward with only a few people. This is something we should respect.

I agree that the "featured label" process isn't ideal and should be improved with clear requirements and so on. But currently it't the only possible sorting criteria which respects contributions outside code commits, helping in issue queues or things we can currently calculate.

Let's talk about a special community contribution like organizing drupalcamps. I was one of the main organizers of the "DrupalCamp Frankfurt 2014". I saw some people investing many time to get this camp realized. There is currently no way to give credit for such contributions on d.o except the "featured label". When you are now thinking about getting sponsorships to camps (which are also very important) we are giving a wrong signal to volunteers out there. It's something like: "Hey, if you have a customer project where you can get paid do this instead. It's better to buy a sponsor package to get a higher place in marketplace as spending time on camp organization".

I think we need a way to respect volunteer time on community organization and use this also for sorting. Until we have another way to calculate this the "Featured label" is still a possibility to realize. On a lower level of sorting criteria I think sponsoring (and other things which are easy to get for bigger organizations) are a good idea. But without community criteria above it would be more unfair than now in my opinion.

Currently the Issue Credits are the only sorting criteria. And it seems that some people are thinking this is a fair and neutral thing and want to prefer against such human controlled criteria like "Feature Label"?
After making some research and tests I have to correct my argument above: It's very easy to push the Issue Credit of a company. You just need contrib modules. There is currently no rule against just open as many issues as you can and "fix" them. And even if somebody is really working on problems and making some contrib code better he/she maybe opens some more issues to fix while keeping the Issue Credits and the marketplace in mind.
The current issue summary here is giving a SEO argument for changing the sorting away from the alphabetical order. But using the trick as described above to push the issue credits is easier as getting backlinks on a webpage to push google pagerank. And especially if some company is aware of SEO for their websites I believe they are also interested to push the Issue Credits. Additional there is also the reputation to get in the marketplace here and a good place in the lists especially in sublists for companies.
Just take a look at the old issues for reviewing company pages to get get in the marketplace or the "Featured Label". There you can see that there are lot's of companies wanting to get in or a better place without or with only a little bit of contributing. The good thing of this reviewing process is that there is a place to discuss contributions. And I believe it's not only missing knowledge that many companies are listed in country lists without physical offices there. With the Featured List this problem was not so important for me. But now I see some companies in the current sorting without contributions and without a physical office in the list of Germany over some heavy contributing companies. For example: "Unleashed Mind" the company of sun and having the "featured flag" as I remember is currently only one place ahead of the last place.

I raised this point in a email to joshuami but I want to quickly (sorry for being brief for now) bring it up again in this issue.

With the current "technical" approach of sorting we are explicitly working against what we tried to achieve (and I argue we successfully did) with the creation of the "featured" listing.

This is our way to say "Thank you" and recognize their continuous support of the Drupal project and its community.

C_Logemann correctly points out that we are starting to ignore all kind of community contributions that make Drupal so special and not just a product (like hosting meetups, organizing camps, local sprints etc). This is a change of direction that would have warranted some community discussion.
Secondly taking over the marketplace by Assoc staff without any discussion also feels wrong. As I understand this whole thing was a community project and it was mostly run by volunteers and not staff.

(Sidenote: Taking over community parts of drupal.org without broader discussion while letting other parts die in a ditch (forums) starts to look really bad. Glad to see bandwith for drupal.org improvements but I don't see the pressing need to prioritize revamping the marketplace (which was working well enough). Just saying.)

I would characterize the changes as automation and the use of objective data related to issue queue contribution to sort. It need not be just code as we use the issue queues for lots of process in the community.

Using issue credits as part of the sort has been in the works for a long time and only just now is there enough issue credits for organizations that we could safely make the switch. The choice of doing it at a DrupalCon were we could celebrate the good work of organizations helping to get Drupal 8 ready for release was intentional.

As for gaming the system, this possibility was brought up during the Drupal 8 Retrospective core conversation at Barcelona. Technically, someone could attempt to game the system by awarding issue credits to a coworker on a small contrib project. However, we only list the last 90 days of issue credits, so the bad actors would have to sustain that effort. We can catch that unpublish their organization and follow up with them.

Improving the software behind Drupal.org is not an attempt to take anything away from the community. We are trying to make the site better for all types of community members.

We should spin off a couple of child issues. I would like to see ideas for how we can collect data from the user groups that organizations are supporting so that we do not have to rely on self-reported contributions. We can start a process with camps to collect data about which organizations are sponsoring camps, but I also think those camps could provide information regarding which organizations are helping plan the camps. Once we have that data we can figure out the math for including it in the sort criteria.

It's very easy to push the Issue Credit of a company. You just need contrib modules. There is currently no rule against just open as many issues as you can and "fix" them.

This same point was raised at the Retrospective with Dries at DrupalCon Barcelona.

A simple fix for this that solves 90% of the problem is to also take the project usage into account. E.g. count each core issue credit as 1, and count each module X issue credit as 1 * percentage of Drupal sites using this module.

#44

A simple fix for this that solves 90% of the problem is to also take the project usage into account. E.g. count each core issue credit as 1, and count each module X issue credit as 1 * percentage of Drupal sites using this module.

That seems sensible.

Even without intentional gaming, there's a big difference between resolving a bug in Views or Panels vs. the first few commits on a new contrib project. If that new contrib project eventually gets high usage then maintaining it when it gets there will mean more commit credit.

Is there a plan how to go about clean URLs (ie branded) for companies? It was a perk of getting featured but that went out the window. What now?

We are planning to add proper url aliases to all organization nodes in the near future (#2615922: Configure path auto for organizations).

Commenting to note that upcoming changes to the marketplace are happening shortly, per these issues:

#2840744: Marketplace ranking algorithm

#2833508: Consider weighting issue credits by project usage when ranking Marketplace organizations

Thanks to all above for their input, we factored what we could into this round of changes, and hopefully there will be more to come. Between these two issues we've got several new factors being considered beyond just issue credit, and we've introduced the notion of usage weighting.

There are still more factors that we'd like to include - helping to organize camps is probably right at the top of that list - but that's a trickier problem to solve since the data on that doesn't reside with us and a self-reported option would require a lot of manual moderation. Needs more thought.

I'm tentatively closing this issue - as I think this issue was very broad in its original problem statement and we may be able to work more easily with more specific proposed changes in individual issues.

Thanks all!