Added gig-marketplace and innersource-portal patterns by stephenmccall · Pull Request #102 · InnerSourceCommons/InnerSourcePatterns

stephenmccall · 2018-07-24T15:06:19Z

Signed-off-by: McCall, Stephen Stephen.McCall@FMR.COM

Signed-off-by: McCall, Stephen <Stephen.McCall@FMR.COM>

NewMexicoKid · 2018-07-24T16:38:04Z

+
+## Solutions
+
+Create an InnerSource Portal intranet website where InnerSource project owners can easily advertise the availability of their projects. Visitors to the InnerSource portal should be able to look across all available projects as well as search for specific projects based on various criteria such as project name, technologies in use, contributor names, sponsoring business unit etc.  The information displayed via the InnerSource portal should be under the full control of the InnerSource project owners at all times and they should have the ability to add or remove projects as needed.  Project owners should include all relevant information concerning their projects within the listings including the owner’s name, the project name and description as well as links to the code repository and any supporting documentation.


Is information manually entered into the portal? Or is there a way to glean it from a well-formatted README.md file so that it is only maintained in one place and doesn't have to be manually kept up to date?

The preferred method would be to source the information displayed via the portal from a data file stored in each project's source code repository. That way the locus of control always remains within the purview of the project owners. We omitted those specifics here as it might have been seen as too prescriptive and implementation specific. That is definitely up for debate.

I think it is helpful to mention it as one option (with the rationale behind it).

I was wondering if you also notify projects which have not yet added a meta-file to their repo and help them improve their visibility by adding one. That's something we're currently planning on implementing.

Yes. Absolutely. We are leveraging the internal InnerSource Forum we've created over the past year and asking all of the project owners attending our monthly meetings to add these documents to their repos.

NewMexicoKid · 2018-07-24T16:39:30Z

+* It is difficult for individuals to discover what InnerSource opportunities exist across the entire company.
+* InnerSource project owners have no clearly defined channel through which to advertise their projects to potential contributors.
+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.
+


Should there be a force around different repositories that might exist across the larger organization? Having multiple repositories could make searching for InnerSource projects more difficult.

Yes. There is a supposition here that a common source control system is in place and that it is permissible for groups within an organization to provide global read access to that source code. This may not exist in some organizations but even if access is restricted to a specific sub-group it does not preclude the usefulness of a portal in that limited context.

Putting on the developer hat for a moment: if I have no visibility into the project which is offering gigs and specifically the sources and the past collaboration, I am less likely to commit to a gig for that project.

True, however remember that the premise is that developers are expected to be searching across the Gigs in the Marketplace to identify projects where they can either demonstrate existing or obtain new skills/experiences. Not necessarily to find opportunities to contribute to projects of which they are already aware.

NewMexicoKid · 2018-07-24T16:40:43Z

+## Resulting Context
+
+The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience.  Due to this increased visibility they are attracting much larger communities of contributors than ever before.  For those looking to get involved in InnerSource projects, the InnerSource portal has allowed them to discover exactly the kind of opportunities they are interested in by searching across all available InnerSource projects simultaneously based on their specific criteria.  Satisfying the needs of both of these audiences has helped establish InnerSource as a viable and attractive option for all areas of the organization to leverage to accomplish things together they could not have otherwise. 
+


It seems like there should be some linkage (and mention) of the Gig Marketplace and how it integrates with the InnerSource Portal.

OK. The two patterns could be used independently though. Would it be enough to mention that the two patterns can be used to better effect in combination?

Yes, I think this would work.

NewMexicoKid · 2018-07-24T16:41:21Z

+
+## Known instances
+
+* A large financial services organization has used the creation of an InnerSource Gig Marketplace website to foster their InnerSource program. 


Is the InnerSource Gig Marketplace website == InnerSource Portal? Or is this mention just left over from the split?

Yes. This was an oversight on my part. I'll remove the mention of the Gig Marketplace from this section of the pattern.

NewMexicoKid · 2018-07-24T16:42:27Z

+## Resulting Context
+
+The InnerSource Gig Marketplace has vastly increased the number of possibilities for InnerSource opportunities. The self-directed nature of Gig Marketplace has enhanced job satisfaction amongst employees by allowing them a level of choice in the work they perform and with whom they can partner across the company. Managers are able to better estimate and track their employee’s time commitments with respect to InnerSource projects, recognize their individual efforts and use the completion of gigs as a way of validating their specific skillsets.  Managers are also able to leverage any existing downtime their employees may be experiencing by allowing them to pivot to work available in the Gig Marketplace.
+


Seems like there should be a linkage/mention of the InnerSource Portal and an explanation of how the Gig Marketplace and InnerSource portal relate to each other.

OK. The two patterns could be used independently though. Would it be enough to mention that the two patterns can be used to better effect in combination?

NewMexicoKid · 2018-07-24T16:44:21Z

+
+## Solutions
+
+Create a “gig” based intranet site where individuals can advertise their skills and areas of interest and project owners can advertise opportunities for collaboration.  Each gig should describe exactly the skill and time requirements needed so those can be easily and clearly communicated to an employee’s direct management.  A points based system should be created to reward and track an employee’s involvement in a gig. Points accrued by completing a gig can then be used as performance management criteria and to garner insight in to the areas of expertise that exist within an organization. All gigs are initially vetted with the Gig owner to determine that the employee has the prerequisite skills and allotted time and needed access to complete the gig.  Gigs can also factor in soft skills such as garnering help organizing a group event or requesting help editing/writing a report or requests for mentorship etc.


Are there some examples you could provide for how you are mapping points to work? Also, is the Gig owner responsible for awarding the points upon successful completion of the gig? Or is there discretion for rewarding points along the way to completion?

We could include the specifics of how the points are being awarded in our implementation. Again, we thought that this level of detail was too implementation specific and better left to those wishing to adopt the pattern. Again, this is all up for debate.

I think this particular detail would be helpful to those looking to adopt this pattern.

Nitpicky detail, I propose to s/can be used as a performance management criteria/could be used as a performance management criteria. In countries like Germany, there are often strict rules which would make that very difficult or impossible. That said, I do like the general idea.

Understood. Will update this language accordingly.

rrrutledge

This is so cool, @stephenmccall. Left feedback on gig-marketplace only (so far).

rrrutledge · 2018-08-01T17:44:29Z

+
+## Problem
+
+There is no single, uniform way for InnerSource project owners and potential contributors to discover each other. 


Does the marketplace help you to discover specific projects, or is it more like discovering tasks of a certain type (no matter to what project they belong)?

FWIW: my understanding is that it's about the latter

That's correct. The InnerSource portal pattern is meant to address the project discovery aspect. The Gig Marketplace pattern is centered around organizing potential contribution opportunities into categories mapping back to individual developer's interests.

rrrutledge · 2018-08-01T17:45:10Z

+## Problem
+
+There is no single, uniform way for InnerSource project owners and potential contributors to discover each other. 
+It is difficult for employees to communicate to their management what commitment of time they will need to make to an InnerSource project and how they will benefit.  


how they will benefit

How does the gig marketplace help to explain the benefit back to the contributor? Not clear.

True. The way it is presented it is just taken as a given that taking on the additional work of a Gig will somehow personally benefit the developer. The marketplace website should list out potential benefits explicitly in its interface or documentation. Also, on top of the time and skill requirements those listing the Gigs should include language in the Gig description stating what could potentially be learnt or the kind of impact someone could have by taking on the Gig.

rrrutledge · 2018-08-01T17:47:22Z

+* There are multiple engineering teams in your organization but few channels through which they can effectively partner on shared challenges.
+* It is difficult for individuals to discover what InnerSource opportunities exist across the entire company.
+* InnerSource project owners have no clearly defined channel through which to advertise their projects to potential contributors.
+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.


This point seems like a key Context to this pattern. In the real world a marketplace thrives when people have resources to spend at the market. I think the same would hold in this marketplace for developer time.

Yes, this is a force. Will move out in to the Context.

rrrutledge · 2018-08-01T17:51:16Z

+
+You’ve successfully created an InnerSource program at your company and have buy-in from senior management, middle-management and developers.  However, after nearly a year there have been few actual contributions made to any InnerSource projects outside of the teams that originally created them.  After interviewing all the parties involved the main sticking point seems to be that it is difficult to know what the exact level of commitment developers will be asked to make if they choose to get involved in an InnerSource project. There is also no uniform way of advertising what opportunities for contributors exist, what they’ll be asked to do and approximately how long it might take.  Managers are supportive and want their employees to participate but so far have lacked a way of documenting and accounting for their employees’ activities within InnerSource projects.  What can be done to improve this situation for all the parties involved (InnerSource project owners, potential contributors and development managers)? 
+
+## Forces


I feel like some of these Forces are written as lack-of-the-solution. I'd advocate for thinking of what is the underlying force that causes a solution to be needed and write that as the Force.

e.g. instead of

It is difficult for managers to approximate what the time/effort commitment will be for employees taking on InnerSource project tasks.

something like

Managers need to plan and account for employees time commitments

or instead of

The less insight a manager has into the effort and accomplishment of their employees in InnerSource projects, the more unlikely it is that he can reward their employees for their InnerSource work.

something like

Managers and employees both want inner source contributions to be rewarded.

Great point. Will go back and rephrase these to follow this more succinct phrasing.

rrrutledge · 2018-08-01T17:51:57Z

+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.
+* It is difficult for managers to approximate what the time/effort commitment will be for employees taking on InnerSource project tasks.
+* The less insight a manager has into the effort and accomplishment of their employees in InnerSource projects, the more unlikely it is that he can reward their employees for their InnerSource work.
+* The transparency and reputational aspect of the code submissions within a large company should work to keep the code quality high for InnerSource contributions.


I'm not sure what this one is trying to get at?

I don't see this concept referred to later on in the pattern, so perhaps it doesn't belong?

OK. Will add language in the solution speaking to the need for code quality based on reputation aspect of the work done as part of a Gig.

I'm also not clear about this one, @stephenmccall . Here's my understanding, reformulated as a force:

The more transparent contributions are made and the more they help a contributor build (or detract from) her reputation, the higher the quality of the contribution will be.

I like it. I'll adopt this language in the updated versions of these patterns I will be submitting via the pull request.

rrrutledge · 2018-08-01T17:52:19Z

+* It is difficult for managers to approximate what the time/effort commitment will be for employees taking on InnerSource project tasks.
+* The less insight a manager has into the effort and accomplishment of their employees in InnerSource projects, the more unlikely it is that he can reward their employees for their InnerSource work.
+* The transparency and reputational aspect of the code submissions within a large company should work to keep the code quality high for InnerSource contributions.
+* Individual employees may commit themselves to InnerSource project tasks without first getting approval from their manager or having the skills or time required to complete it.


Feels more like a Context to me (something we want to change through this pattern!)

OK. Will consider rewriting this to express it more as a force.

FWIW, I agree with Russ.

OK. Instead of rewriting this as a Force will move it in to the Context section.

rrrutledge · 2018-08-01T17:53:38Z

+* The transparency and reputational aspect of the code submissions within a large company should work to keep the code quality high for InnerSource contributions.
+* Individual employees may commit themselves to InnerSource project tasks without first getting approval from their manager or having the skills or time required to complete it.
+
+## Context


Oooh, these look like Forces to me. They are not going to change based off of the application of the pattern.

We may have an opposite understanding of what is a Force and what is Context? 🤷‍♂️

OK. Will consider rewording so that these better describe forces. These are potentially better expressed as forces that make people act in a certain way or take certain actions.

Well, I think the bullet points on tacid acceptance and corporate policy are in fact proper elements of the context. The other ones I would also try to move to the forces section as they are all relevant for the core of this pattern.

From past discussions, I remember you brought up some more aspects that helped you set up the Gig Marketplace, @stephenmccall . Something related to you being part of an org that was capable and experienced in setting up tools like the Gig Marketplace. Those should be added in the context, as well, if they help a reader decide, whether or not this pattern might help them.

Good point. Yes. The two divisions responsible for standing up the InnerSource portal and the Gig Marketplace were both under the umbrella of Enterprise Architecture. This is important to point out as their central role is understood across the firm as one that should be providing centralized tooling to the rest of the organization. It would be more difficult to imagine, for example, a Marketing or HR division garnering the funding or support to create such tools for the rest of the company.

gruetter · 2018-08-13T15:25:50Z

+
+## Problem
+
+There is no single, uniform way for InnerSource project owners and potential contributors to discover each other. 


FWIW: my understanding is that it's about the latter

gruetter · 2018-08-13T15:33:27Z

+* It is difficult for individuals to discover what InnerSource opportunities exist across the entire company.
+* InnerSource project owners have no clearly defined channel through which to advertise their projects to potential contributors.
+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.
+* It is difficult for managers to approximate what the time/effort commitment will be for employees taking on InnerSource project tasks.


This is going to be a bit meta ... I personally prefer forces to be written in a way that explains the effect of a force and - by extension - explain what would happen if one were to eliminate that force. The latter is how patterns work. So in this case, I would reformulate to something like

Managers who can't approximate the required time/effort for InnerSource project tasks are less likely to commit their employees to doing them.

OK. Will update this language accordingly.

gruetter · 2018-08-13T15:38:53Z

+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.
+* It is difficult for managers to approximate what the time/effort commitment will be for employees taking on InnerSource project tasks.
+* The less insight a manager has into the effort and accomplishment of their employees in InnerSource projects, the more unlikely it is that he can reward their employees for their InnerSource work.
+* The transparency and reputational aspect of the code submissions within a large company should work to keep the code quality high for InnerSource contributions.


I'm also not clear about this one, @stephenmccall . Here's my understanding, reformulated as a force:

The more transparent contributions are made and the more they help a contributor build (or detract from) her reputation, the higher the quality of the contribution will be.

gruetter · 2018-08-13T15:39:48Z

+* It is difficult for managers to approximate what the time/effort commitment will be for employees taking on InnerSource project tasks.
+* The less insight a manager has into the effort and accomplishment of their employees in InnerSource projects, the more unlikely it is that he can reward their employees for their InnerSource work.
+* The transparency and reputational aspect of the code submissions within a large company should work to keep the code quality high for InnerSource contributions.
+* Individual employees may commit themselves to InnerSource project tasks without first getting approval from their manager or having the skills or time required to complete it.


FWIW, I agree with Russ.

gruetter · 2018-08-13T15:44:33Z

+* The transparency and reputational aspect of the code submissions within a large company should work to keep the code quality high for InnerSource contributions.
+* Individual employees may commit themselves to InnerSource project tasks without first getting approval from their manager or having the skills or time required to complete it.
+
+## Context


Well, I think the bullet points on tacid acceptance and corporate policy are in fact proper elements of the context. The other ones I would also try to move to the forces section as they are all relevant for the core of this pattern.

From past discussions, I remember you brought up some more aspects that helped you set up the Gig Marketplace, @stephenmccall . Something related to you being part of an org that was capable and experienced in setting up tools like the Gig Marketplace. Those should be added in the context, as well, if they help a reader decide, whether or not this pattern might help them.

gruetter · 2018-08-13T16:03:49Z

+* There are multiple engineering teams in your organization but few channels through which they can effectively partner on shared challenges.
+* It is difficult for individuals to discover what InnerSource opportunities exist across the entire company.
+* InnerSource project owners have no clearly defined channel through which to advertise their projects to potential contributors.
+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.


This should go in the context section.

OK. Will move in to the context section.

gruetter · 2018-08-13T16:06:38Z

+* It is difficult for individuals to discover what InnerSource opportunities exist across the entire company.
+* InnerSource project owners have no clearly defined channel through which to advertise their projects to potential contributors.
+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.
+


Putting on the developer hat for a moment: if I have no visibility into the project which is offering gigs and specifically the sources and the past collaboration, I am less likely to commit to a gig for that project.

gruetter · 2018-08-13T16:08:35Z

+
+* Managers have given tacit acceptance that their employees should take part in InnerSource projects
+* Employees desire the ability to be made aware of all of the InnerSource project activity occurring across the compnany
+* Owners of InnerSource projects desire the ability to attract as many potential contributors to their projects as possible


Putting on the community leader hat now: I'd rather have a small but very competent team rather than a large team of newbies.

Agreed. However, the premise is that the Gig Marketplace would be most attractive to project owners who are attempting to establish even that first small core community of developers and less to those that already being run by a team of familiar trusted contributors.

Given that though, perhaps there should be some mention of that somewhere in the pattern. That the Gigs posted to the marketplace can be used to attract an initial audience.

gruetter · 2018-08-13T16:11:32Z

+* InnerSource project owners have no clearly defined channel through which to advertise their projects to potential contributors.
+* Individuals have been given some time by their management to get involved in InnerSource projects of their choosing.
+
+## Context


Tools like GitHub and Bitbucket offer limited support for discovering projects, if the overall number of projects is very high. GitHub offers a few marketing tools, but nothing like what you propose. I feel that should go in the context as well.

Good point. This is a bit of an unspoken truth. If popular tools like these did allow for such easy discovery based on similar criteria then that would obviate the need to create a bespoke Gig Marketplace application in the first place. There might still be a need for this pattern but the implementation recommendations would be more akin to suggestions to leverage these features within popular SCM tools.

gruetter · 2018-08-13T16:13:40Z

+
+## Solutions
+
+Create an InnerSource Portal intranet website where InnerSource project owners can easily advertise the availability of their projects. Visitors to the InnerSource portal should be able to look across all available projects as well as search for specific projects based on various criteria such as project name, technologies in use, contributor names, sponsoring business unit etc.  The information displayed via the InnerSource portal should be under the full control of the InnerSource project owners at all times and they should have the ability to add or remove projects as needed.  Project owners should include all relevant information concerning their projects within the listings including the owner’s name, the project name and description as well as links to the code repository and any supporting documentation.


I was wondering if you also notify projects which have not yet added a meta-file to their repo and help them improve their visibility by adding one. That's something we're currently planning on implementing.

shellyniz · 2018-08-18T13:25:48Z

We are at the process of adding such a Market Place in my corporate (using gitlab API), but we are also adding a match maker functionality, meaning developers define their set of skills and skill they would like to become better at and the web site would automatically offer a list of projects matching their interest,

We already have a gamification platform, and we plan to incorporate the Market Place into the game as developers will probably need some motivation to add this data to their profile.

We are also planning to set some of the projects meta data automatically by using Gitlab API and gathering data about's repositories programming languages (same about developers)

Think any of those can/should be included in the pattern?

stephenmccall · 2018-08-23T15:04:22Z

As part of the most recent commits to this pull request I've updated both the innersource-portal and gig-marketplace pattern documents to reflect the suggestions and requested changes that surfaced as part our subsequent reviews. If everything looks good for the most part I can resubmit each in a separate branch and pull request as is suggested in the project documentation.

spier · 2020-03-14T13:53:04Z

Looks like both of these patterns are already in master, therefore GitHub has marked this branch as out of sync with master.

Both Patterns seem to be in Maturity Proven (more specifically Reviewed Patterns (proven and reviewed).

Files in master:

gig-marketplace.md
innersource-portal.md

So I think that we can close this PR and delete the branch?

rrrutledge · 2020-03-16T21:38:59Z

Sounds good to me.

lenucksi · 2020-03-22T18:05:41Z

Merge conflict looks mostly like formatting issues with otherwise similar content, I'll take further look, resolve it, see if we can close it due to "already merged" and add a comment otherwise

lenucksi · 2020-08-10T16:24:22Z

I took a look and there are relevant changes in this pull request against the version currently in the master branch.
There's also quite a bit of extra, open discussion here that we should take into account.
Since this pull request came from @stephenmccall's employer GitHub-org, the Fidelity org, and Stephen is no longer there we can only close or merge this as is and continue to add in more changes in a future pull request.
I argue we should try to resolve as many discussions as possible that can be resolved without changes, then merge and continue the discussions that need changes in a new pull request.

lenucksi · 2020-09-17T13:11:25Z

#101 is likely related

lenucksi · 2020-09-28T18:53:10Z

I've changed the base branch here to a separate branch merge-fidelity-pr102 on this repository. I'll merge this PR into said separate branch now and create a new pull request referencing this one that merges toward master. That way we will be able to add in any insight we might see from the discussions in the review comments of this pull request without having access to the fmr-llc org.

Added gig-marketplace and innersource-portal patterns

d505f4c

Signed-off-by: McCall, Stephen <Stephen.McCall@FMR.COM>

NewMexicoKid reviewed Jul 24, 2018

View reviewed changes

rrrutledge reviewed Aug 1, 2018

View reviewed changes

gruetter reviewed Aug 13, 2018

View reviewed changes

Updated files to include feedback from original PR

2b9206b

lenucksi added 5 - Accepted 3-validated Patterns proven in multiple cases with advanced requirements (Please see our contribution handbook) Type - Maintenance / Cleanup Maintaining / cleaning the repo is the main focus of this issue / PR labels Mar 22, 2020

maxcapraro added the Stale We mark issues as stale after 90 days of inactivity. This does not make any judgement about value. label Apr 21, 2020

spier mentioned this pull request May 7, 2020

New folder structure for Patterns #154

Closed

lenucksi added 📖 Type - Content Work Working on contents is the main focus of this issue / PR and removed 5 - Accepted labels Sep 17, 2020

lenucksi changed the base branch from master to merge-fidelity-pr102 September 28, 2020 18:49

lenucksi requested review from cewilliams, lenucksi and nyeates as code owners September 28, 2020 18:49

lenucksi merged commit 0a21a3a into InnerSourceCommons:merge-fidelity-pr102 Sep 28, 2020

lenucksi mentioned this pull request Sep 28, 2020

Complete review + merge of PR #102 from the Fidelity org: InnerSource-Portal Pattern #227

Closed


		## Solutions

		Create an InnerSource Portal intranet website where InnerSource project owners can easily advertise the availability of their projects. Visitors to the InnerSource portal should be able to look across all available projects as well as search for specific projects based on various criteria such as project name, technologies in use, contributor names, sponsoring business unit etc. The information displayed via the InnerSource portal should be under the full control of the InnerSource project owners at all times and they should have the ability to add or remove projects as needed. Project owners should include all relevant information concerning their projects within the listings including the owner’s name, the project name and description as well as links to the code repository and any supporting documentation.

		## Resulting Context

		The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience. Due to this increased visibility they are attracting much larger communities of contributors than ever before. For those looking to get involved in InnerSource projects, the InnerSource portal has allowed them to discover exactly the kind of opportunities they are interested in by searching across all available InnerSource projects simultaneously based on their specific criteria. Satisfying the needs of both of these audiences has helped establish InnerSource as a viable and attractive option for all areas of the organization to leverage to accomplish things together they could not have otherwise.


		## Known instances

		* A large financial services organization has used the creation of an InnerSource Gig Marketplace website to foster their InnerSource program.

		## Resulting Context

		The InnerSource Gig Marketplace has vastly increased the number of possibilities for InnerSource opportunities. The self-directed nature of Gig Marketplace has enhanced job satisfaction amongst employees by allowing them a level of choice in the work they perform and with whom they can partner across the company. Managers are able to better estimate and track their employee’s time commitments with respect to InnerSource projects, recognize their individual efforts and use the completion of gigs as a way of validating their specific skillsets. Managers are also able to leverage any existing downtime their employees may be experiencing by allowing them to pivot to work available in the Gig Marketplace.


		## Solutions

		Create a “gig” based intranet site where individuals can advertise their skills and areas of interest and project owners can advertise opportunities for collaboration. Each gig should describe exactly the skill and time requirements needed so those can be easily and clearly communicated to an employee’s direct management. A points based system should be created to reward and track an employee’s involvement in a gig. Points accrued by completing a gig can then be used as performance management criteria and to garner insight in to the areas of expertise that exist within an organization. All gigs are initially vetted with the Gig owner to determine that the employee has the prerequisite skills and allotted time and needed access to complete the gig. Gigs can also factor in soft skills such as garnering help organizing a group event or requesting help editing/writing a report or requests for mentorship etc.


		## Problem

		There is no single, uniform way for InnerSource project owners and potential contributors to discover each other.


		You’ve successfully created an InnerSource program at your company and have buy-in from senior management, middle-management and developers. However, after nearly a year there have been few actual contributions made to any InnerSource projects outside of the teams that originally created them. After interviewing all the parties involved the main sticking point seems to be that it is difficult to know what the exact level of commitment developers will be asked to make if they choose to get involved in an InnerSource project. There is also no uniform way of advertising what opportunities for contributors exist, what they’ll be asked to do and approximately how long it might take. Managers are supportive and want their employees to participate but so far have lacked a way of documenting and accounting for their employees’ activities within InnerSource projects. What can be done to improve this situation for all the parties involved (InnerSource project owners, potential contributors and development managers)?

		## Forces

Conversation

stephenmccall commented Jul 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rrrutledge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!