I think that generally this title is much shorter - using the same words as the file name. The "normal" title for this document would be something like: Gig Marketplace.

Great point Russ. "Gig Marketplace" it is. 👍

Kind of sounds a bit like Top Coder but internal to the company?

That's the general idea, but the intended outcomes are so much different. The Gigs posted are also used as "proof of ability" for the developers accepting them after they are completed. Another main objective is for developers, not managers, to post Gigs allowing them to work with one another to accomplish just about anything they can think of. It's a mechanism that flattens the organizational hierarchy, ignores BU affiliations and opens up the whole company wide development community as a resource for anyone to potentially leverage.

Fun!

Intriguing idea, @stephenmccall !

Based on comments from @rshanmer : looks good, length wise. Also focuses on solution, which is how it should be�. Possible elaborate on the content of the 2nd sentence.

from @NewMexicoKid : Would it be helpful to introduce a length limit of patlets?
@rshanmer : Maybe limit to two sentences, instead of going for a #characters limit.
all: two sentences sounds like a reasonable choice.

Thanks for including the patlet! I think it would be good to include a sentence about the problem that this pattern is trying to solve and also reduce the description of the solution to just 1-2 sentences.

Is this at-odds with this line in the Context?

Individuals have been given some time by their management

Maybe not "at odds" with but these sections of the pattern do need to be better balanced. This is where we could really use some help from the rest of the forum who might have more experience authoring other patterns.

Sounds like a good topic for the call.

Recommend rephrasing some of these lines to reference why the particular activity is important instead of just saying that the activity isn't happening.

e.g. Managers have no way of understanding what the time/effort commitment is for their employees wanting to get involved in an InnerSource project outside of their business unit becomes sometime like Part of a manager's job is tracking, estimating and understanding use of employee time.

True. Good point. We should also edit this to include more of the motivations behind why individuals would want to take on a Gig. To learn a new skill, demonstrate expertise, help someone out etc... Right now it is too "manager"-centric. The Gig Marketplace is actually something that benefits individual employees from a professional development perspective more than it does managers looking for assistance in getting day to day work completed.

Sounds good. Looking forward to continuing to work on this pattern together!

Based on the context and forces it sounds like there are a few other problems that this pattern helps to solve (e.g. estimating commitment and tracking achievements).

Exactly. The "tracking achievements" part is probably the most compelling. Although being able to communicate exactly how much time you are expected to spend on the task is a huge selling point for those looking for approval from their direct management to get involved.

That's cool. I (personally) think it would be fine to list out multiple problems that this pattern addresses.

Here I go again ;). I propose to state the problem more clearly and explicitly in the problem section. I guessing the problem is that opportunities for collaboration are wasted?!

Suggestion from the group: split this pattern in two:

1. Publish InnerSource projects on easily accessible website
2. Establish Gig Marketplace to ....

from @rshanmer : The Gig Marketplace seems to solve multiple problems. Find stuff to work on. Also making mgmt. comfortable with their people working on InnerSource management.
from @stephenmccall : The original focus of the Git Marketplace was the performance management directed toward people.
from @russ: Feels that the patter should on performance management
frpm @daniel: Does this depend on existence of trusted committers, contribution guidelines e.t.c.?
from @stephenmccall : These topics are closely intertwined.
from @daniel: Also closely linked to problem of findability
from @NewMexicoKid and @dicortazar : let's add links to related patterns whereever the related patterns are mentioned.

Can delete this section.

Agreed. Will delete.

Maybe some of the no way assertions here are a little strong? Could just say that it's "difficult" to make the pattern more broadly-applicable?

True. We should soften that language for the general pattern. In fact, this entire section should most likely be rewritten to speak more about the motivations for creating a Gig Marketplace as opposed to InnerSource projects per se.

This piece of context and detail feels specific to an instance of application of this pattern rather than a core part of the pattern itself?

Completely agree. Again, this is a holdover from a previous document describing the relationship between the InnerSource program at Fidelity in general and how it relates to the Gig Marketplace. We should only be talking about the Gig Marketplace in the "Gig Marketplace" pattern! :)

It's neat to see parts of this resulting context referencing items in the original context. Some of the original points of context are not referenced in this result, though (e.g. insight of managers to what their employees are doing). Recommend talking about the resulting context for each point of the original context.

Agreed. I'd like to sort out what to include as part of each of these sections as part of our next group review.

Sounds good.

Fun!

That's cool. I (personally) think it would be fine to list out multiple problems that this pattern addresses.

Sounds good. Looking forward to continuing to work on this pattern together!

Sounds like a good topic for the call.

Sounds good.

Some alternative language (if you like it): ... multiple pockets of engineering in ...

Based on comments from @rshanmer : looks good, length wise. Also focuses on solution, which is how it should be�. Possible elaborate on the content of the 2nd sentence.

from @NewMexicoKid : Would it be helpful to introduce a length limit of patlets?
@rshanmer : Maybe limit to two sentences, instead of going for a #characters limit.
all: two sentences sounds like a reasonable choice.

Suggestion from the group: split this pattern in two:

1. Publish InnerSource projects on easily accessible website
2. Establish Gig Marketplace to ....

from @rshanmer : The Gig Marketplace seems to solve multiple problems. Find stuff to work on. Also making mgmt. comfortable with their people working on InnerSource management.
from @stephenmccall : The original focus of the Git Marketplace was the performance management directed toward people.
from @russ: Feels that the patter should on performance management
frpm @daniel: Does this depend on existence of trusted committers, contribution guidelines e.t.c.?
from @stephenmccall : These topics are closely intertwined.
from @daniel: Also closely linked to problem of findability
from @NewMexicoKid and @dicortazar : let's add links to related patterns whereever the related patterns are mentioned.

from @rshanmer : the last two bullet points should go into the forces section

from @dicortazar : we might be able to measure this, actually. People might not just be aware how
from @stephenmccall : yes, this is probably too strict. Soften statement a bit.
from @dicortazar and @stephenmccall : suggestion: "peoples activities and specific contributions are currently not tracked so managers don't know how to reward it"

from @rshanmer : should go into the problem section of the other (new) pattern

from @stephenmccall : add: "the Gig Marketplace allows you to validate employees skill sets."

from @stephenmccall : it helped that the BU which started the portal had responsibility for similar type of systems/portals.

from @rshanmer : add a first "do-this" sentence to the solution along the lines of "create a marketplace for InnerSource Gigs/needs"

from @stephenmccall : propose to remove this bullet point altogether

from @dicortazar : we are using the specific word marketplace but there's no mention of selling anthing
from @stephenmccall : what are the buyers and sellers?
from @dicortazar : different BUs are offering time, capacity or money (sellers) and the developers (BU) could use that (buyers). How are the "selling" BUs reimbursed for their offering?
from @stephenmccall : the reward is being able to say "I did this". There are no physical rewards attached to work done.
from @dicortazar : the developers are being rewarded by their organization. It would be a good idea for the selling business units to be reimbursed by the "buying" business units.
from @stephenmccall : this should happen at some point, but we wanted to start this as "pro bono" to get things going. Might evolve to Daniels suggestion.
from @rshanmer : related to the performance management section. There are three parties: management rewarding their developers for doing work for a 3rd party (as part of performance management). I feel this constitutes a marketplace.
from @stephenmccall : there is inherent benefit in doing the work itself. Unsure whether there need to be additional benefits
from @NewMexicoKid : is it also a people marketplace? A tool for BUs to find people with certain skills? What implications might that have for the "buying" business units? (loosing their best people?)
from (unattributed): Talent hoarding can be a problem in companies; people's mobility around the company is limited. There was a program to solve this: You can allow people to secretly share their resume. This can be tied into this same idea.