Drupal to Backdrop conversion matchmaking system #974
Comments
|
There was some discussion of whether we start with a fully automated system or one with human intermediaries. Whichever we do, we should at least design a fully automated system as our end goal. Then we can see if it would be easier to do part of with a human intermediary to start (and it may not be). If a fully automated system is not that hard to set up, then we might as well set it up from the get-go. |
|
Here's a fairly simple system that I think would accomplish the goals articulated at the meeting:
The module to do that third part is very straightforward to code up, and if we end up with something close to this, I'm happy to raise my hand to put it together. (If we end up with something more complicated than this, not necessarily.) One of the alternative models that was suggested at the meeting was that client submissions would be posted on a page that developers would have to go visit to see what opportunities there are. I think that would raise a couple of problems:
Now, the "instant delivery of email" model does create its own potential issues:
Happy to hear others' thoughts, proposals, and models. |
:) This is quite interesting. I agree with the problems and proposed solutions as presented by Robert. I also think that if Backdrop is to appear to be a proactive "partner" with d.o/DA in actually giving D7 a soft landing, then we need to choose solutions that are more active and less passive, as in sending emails and not requiring people to go visit a website on a regular basis. The worst thing we could do is say we're going to be in this position, and then have requests languishing unresponded to, etc. Regarding the last point about spam, I think if someone seriously wants to explore the idea of hiring a developer to migrate their D7 site to Backdrop, it is not an unreasonable request to have them create an account on b.o or some subsite, which might also vet them a little bit. On the other side of that, do we want to vet the developers who sign up for this? I am quite sure there are a number of people and companies listed on https://backdropcms.org/support/services and https://backdropcms.org/support/services/contractors?expertise=All who have never done anything on Backdrop and only put their name on that list in the hope that someone would hire them. As a test, I chose one at random and went to their published website, and I could find no mention of Backdrop anywhere on their site. |
|
I'm very firmly of the opinion that we need to vet the developers on the list. There are people who have done some backdrop stuff in the past but no longer touch it and probably aren't interested, there are people who have come to the community, say they want to help, ask about jobs and then we don't hear from them again, though they will popup if someone says they have work. I do think we need to first invest some time in pruning the list of contractors and service providers. It would also be good to be able to join together the service providers and contractors; I have a contractor listing and a service provider listing, but there is no link between the two for the visitor. We also need to fix the list of projects on contractor profiles as some are very broken any show loads of projects that they've never, but it's picking them because they have a short user name that appears in lots of other words - see #837 |
|
Incidentally (but relevant to this): the contractors pages are working again: |
Agreed, in principle, but I'm wondering how to do that in a way that doesn't create a lot of manual work and/or delay in the process. As a potential client, I'd think I'd like to see something "a list of 1–3 Backdrop projects you've done" as part of the vetting criteria, but how to automatically ensure (a) that the sites are really Backdrop sites, (b) that they're really the work of the contractor and not some random Backdrop sites they found just to have something on their spam profile—that seems challenging. Thoughts? |
|
The proposal for a page on b.org wouldn't require developers to remember to
check it, or create a habit, they would get an email, same as the webform
option. The only difference would he that email would link to the public
page stating that a new project was posted.
This eliminates both the problem of spam landing in developer inboxes, and
avoids creating an "insiders only" program you'd need to know about to
participate in.
Because we're want both people posting projects, and people seeking
projects to participate The fewer things we do in private, the better.
I'm also against vetting developers/agencies, at least to start the
program. But let's create a follow up issue to discuss requirements we
think would be reasonable (and how to collect them). I don't think 3
backdrop sites is reasonable because there are plenty of Drupal agencies
that wouldn't qualify, but would be great (Lullabot, for example).
…On Sat, Jan 7, 2023, 3:42 PM Robert J. Lang ***@***.***> wrote:
I'm very firmly of the opinion that we need to vet the developers on the
list. ... I do think we need to first invest some time in pruning the list
of contractors and service providers.
Agreed, in principle, but I'm wondering how to do that in a way that
doesn't create a lot of manual work and/or delay in the process.
As a potential client, I'd think I'd like to see something "a list of 1–3
Backdrop projects you've done" as part of the vetting criteria, but how to
automatically ensure (a) that the sites are really Backdrop sites, (b) that
they're really the work of the contractor and not some random Backdrop
sites they found just to have something on their spam profile—that seems
challenging.
Thoughts?
—
Reply to this email directly, view it on GitHub
<#974 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADBER44SYOZ2P5PY73ZKSDWRH5QBANCNFSM6AAAAAATTRATHQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I've created #977 to discuss vetting criteria. I don't think what I've proposed is unreasonable. I think that an email saying a new project has been posted but requiring developer to go to the page is perfectly reasonable. If a developer is looking for work, then this is not too onerous, if they're too busy, then can ignore. |
Agreed. Two issues that come to mind with such a page (both addressable, I think) are:
|
|
Correct me if I'm wrong, but I think @jenlampton was proposing that the submitter would create a node rather than a webform. I do agree that many submitters would not want details of projects and the organisations behind them to be public. I responded to a job posting in the forum and it was only during the initial video call that I found out who the client is. I agree that access should be limited. re: Staleness - it might be better to allow them to unpublish rather than delete, so there is a bit of traceability. It would also be good, if possible, to get the reasons for taking down the listing (i.e. appointed contractor, cancelled project, pursuing a different CMS solution) |
Yep, and we could still allow the authors permission to delete/unpublish the submission.
I don't think there's a use-case for a matchmaking system where the information about the projects are kept private. Most people who have information that needs to be kept private wouldn't put any of it into a system like this, even if the system claimed to keep the submissions confidential. It's just too much risk for them.
Exactly. These folks might use a matchmaking system, but they wouldn't provide any details that need to be kept private until they have a person to talk to. I think we should make it clear in the instructions that anything private should be communicated directly between the two parties (and not communicated to "us" at all). That would also eliminate any risk that we might mishandle private information.
If we don't have any private data to protect, then we won't need to build in additional protections :) I'd also like to restate my concern that the matchmaking system won't work unless people know it exists. Since we're generally pretty bad at notifying people that things exist, it would be best if people could find the tool by searching for it. And if they can see the tool (not just some text explaining that tool exists somewhere that's hidden) then they will be more likely to give it a try. |
|
If we go with the "create a node" route, then we could use Rules to trigger an action when a new node is created, and the only new code needed would be a Rules action to send emails to all contractors. (I'm guessing that we'd want to send individual emails, rather than a single with a BCC list (?).)
Completely agree with this! part of the design of this new process is "where does it appear on b.org, and what does it say there?" I initiated this issue in response to the presentation by @cellear (introduced by @stpaultim), and it would be great to get their input on this discussion and where it seems to be heading. |
That depends on the number of messages that get sent and the number of recipients for each message. If only a few go out a month and each one only has a few recipients, then that is probably fine. However, if several a month are going out and there's tens to hundreds of recipients per message, it will be easier on the system and pocketbook to send as a BCC and let the mail server(s) deal with splitting the messages out to the individual recipients. Just make sure there is also a To address, as not every email client handles situations well where there are only BCC addresses. |
If we do that, then implementation-wise, the only extra code we'd need is a token that gives the email addresses of all of the contractors in a comma-separated list; then Rules could handle sending out the notification when a new opportunity node is created. |
|
I don't think we have Rules on b.org, and I'd like to keep it that way :) (don't get me started on Rules...). We already have a pattern for sending emails to a list when nodes are created (we do this for security advisories), and we should probably stick to doing things only one way for sanity. |
|
Sure. Just trying to minimize custom code. |
|
Hi everybody! Sorry for being absent. I saw the initial creation of this issue that @bugfolder tagged me in, but then didn't see the interesting discussion that followed until he pointed me back here yesterday. Mea Culpa, let me catch up. My vision for this facility to is to keep it as simple as possible, so that we get a useful result without unnecessarily committing more of our scarce resources than we have to. so to keep things simple, let me express the formula I have in mind:
For the second one, minimizing risk, I think it helps to limit communications to just those involved. I don't think the submissions or the responses should be publicly visible. The only people who should see a submission are those that have suggested they might be willing to act on them. That's why I assumed we would just use email in one form or another. If it's easier, we can create nodes or posts or other computer entities, but even if we do that they should act like email: It gets delivered from the sender to the recipients, and shouldn't be trivially visible to outsiders. In terms of minimizing anxiety: I certainly don't think the responses should be visible for longer than it takes to respond to them. I envisioned it as a batch email, with a scheduled delivery. That way, the original requester knows when to expect an answer, and the respondents don't have to feel like they're racing the others to be first in. A request comes in, you have a week or so to ponder and respond, then the requester gets all the responses at once. Sort of like an "RFP" but WAY lighter. Instead of a giant report, the response is just "yes, I've read your description of what you need and I'm interested." In terms of minimizing effort: I wanted to (and still want) to avoid prerequisites as much as possible. I'm familiar with writing software -- it's hard! So I didn't want to assume we would write anything for this, or even configure very much. It's mostly just set a policy and go. So while I have no objection to writing a module to get it done, I don't think it's really necessary. But if it's easy, I have no objection. Similarly, vetting providers seems like a LARGE increase in effort, and inherently contentious. If we want to set up a system to qualify developers, let's do that separately. I don't think we need a formal system to start with -- we'll be watching this, and can jump in a fight fires if any break out. I don't really anticipate that happening, but we can deal with it if it does. |
|
My concern is that if we start it out as described above, we make this less likely to be effective, less likely that anyone will want to do it, and it will end up dying before it has a chance to get off the ground. Right now, we have zero people who have requested to receive this list of possible contracts, and zero people who have contracts to submit. Do you have any ideas about how to generate these lists? While our numbers are near-zero in both categories, having a potential contract available for only a week makes it far less likely that anyone will get connected. This differs from the reality of the contract: it will remain available until it is fulfilled.
This sounds like a much harder system to build, actually... thinking... We could use a flag on the contract node, and interested parties could click the "interested" flag. That could generate a list of links to these user profiles visible to the node author...
We'd still need to schedule the email sending to happen independant of anything else, and we don't have anything that can do that yet. It would be much easier if we could put the burden onto the people who want the work, and ask them to contact the contract owner. I don't think eliminating the race is worth the extra burden. |
Have you looked at that ticket (#977) yet? I want people to tell the truth about what they do for Backdrop on their contractor profile. Is that contentious? Is that not worth the effort? There are already people in that list with false claims about what they do for the Backdrop community; we should prevent fires if we know they are likely to start rather than waiting to put them out. |
I love the idea of having a system to vet developers. I just don't think it should be a prerequisite for the D2B Pipeline project. It's hard enough to get things out of the gate! Once a vetting system exists, we can fold it in. |
Yes, lots. :) One of the key parts of this is exploring various ways to promoting a product, but that requires having a product to promote.
I realize I'm asking you to trust my intuition on this, but I'm counting on simplifying the product to make the messaging more effective. I've informally determined that we have enough resources within the local community to handle the first handful (1-5?) of responses. Polling the listed providers could turn up more, maybe quite a few more. (That includes generating interest among providers who might not be ready to sign up just yet, but could jump in later.) Once there's a product to "sell," I (and others) can try all sorts of ways to drum up interest. This is the biggest unknown, but it should be interesting no matter what, and perhaps it's a big seller. The ideal scenario is that we have more demand for conversions than we do suppliers, because then I/we can approach non-Backdrop agencies and pitch the benefits of Backdrop to do them.
Well, it's easy to do manually, which is why I was proposing that out of the gate. I don't think it's hard to automate, however. Cron job runs once per period -- I suggested a week, but it could be longer. The job checks "Are there any submitted proposals? If so, send them to the list of providers." That doesn't sound hard to me, but just in case it was I proposed doing it by hand. To return to the opening point: I think batching up the responses is REALLY important! It helps in both directions.
If they do get zero responses, they can re-submit, but I don't think that will happen, at least at first -- providers have already signed up on the list saying they're interested. (If everybody is busy, it means I/we need to dig up more providers.) |
|
Sorry for the tardiness on this reply.
Maybe I don't understand what you are saying here, but I think doing it this way will reduce participation. If someone creates a request and it takes a week for them to even know if anyone is even interested, they will likely go elsewhere to seek the assistance they want, especially if they are not 100% sure about whether they are going to use Backdrop or not. If batching is important, I think it is even more important that people have some idea whether their time and effort are fruitful or not. Personally, I would probably never subscribe to such a system.
Again, maybe I don't understand what you are saying here, but I think that is not entirely correct. We do not have lists of these people, because we don't have lists or the places to produce the lists. We DO have people who have made requests: in the forums, in Zulip, in issue queues, and privately. Saying we don't have them because there is no place for them to be does not mean they don't exist.
I don't consider that a predictable outcome. It might only be a predictable response from the system, if the system also sends out a message that says no one responded.
I wouldn't waste my time doing that. Instead, I would assume Backdrop to not be/have an active community and go elsewhere. For someone who has a business and who wants to know whether they can proceed with their plans or not, this does not sound like a good idea. They are spending time now trying to figure out if this is the path forward they want to take. They likely won't want to wait a week to even find out if anyone is going to consider helping them or not. I, personally, have gone through that with other products in the last couple of years. If a product or community even looks dead, I'm moving on. I'm not wasting my time, and I'm not even giving them the chance to prove me wrong. Yes, Backdrop looks alive for someone like us, but for someone who is not a developer or in the community or "in the know" and who is looking for a product, do they even know what to look for to tell if a product or community is alive or not, and would they think that waiting a week to find out would be a good idea? If you want to batch responses, I think they should be done daily, so whoever is considering investing time, money, resources can tell rather quickly if what they are seeking is viable or not. |
|
@cellear wrote:
@oadaeh wrote:
I, too, am in the camp of not wanting to batch-and-wait. As a site owner seeking a developer (which i've been in the past), I would want to get a reply to my query as soon as possible. As a developer sending a reply, I would want the client to get my interest as soon as possible. Introducing an artificial delay would probably disappoint a lot of both ends of the transaction. I understand the motivation for the batching was to "eliminate the race," but I don't think that race is such a bad thing that it warrants introducing the batching delays. (And I agree with a point made above, that a system without batching would probably be easier to build.) |
|
I totally agree. If a developer (I am one) has capacity for work then responding quickly to express an interest and start dialogue is not onerous and should be done quickly. If someone needs a week to think about it, they probably don't need the work. |
At the Community meeting this week, there was discussion and presentation from @cellear on a proposed system for us to facilitate making matches between website owners needing conversion assistance and developers who can help with that. Luke showed a draft webform from our beta site (at path /i/d2b-conversions). A spirited discussion ensued.
Since we're talking about an infrastructure that will reside on b.org, I'm opening this issue to provide a persistent place to capture further discussion (meetings get forgotten, the meeting chat vanished, videos are hard to scrub through, Zulip scrolls rapidly into oblivion). And I've thought of some further points that I'll add to this issue.
@stpaultim, @jenlampton , @yorkshire-pudding, @keyserjb, sorry if I left anyone out.
The text was updated successfully, but these errors were encountered: