Skip to content
This repository has been archived by the owner on Mar 20, 2021. It is now read-only.

InnerSource commons history #82

Open
dellagustin opened this issue Feb 10, 2020 · 7 comments
Open

InnerSource commons history #82

dellagustin opened this issue Feb 10, 2020 · 7 comments
Assignees

Comments

@dellagustin
Copy link
Contributor

dellagustin commented Feb 10, 2020

I am creating this issue as a follow up of the this InnerSource slack thread:
https://innersourcecommons.slack.com/archives/C04PXKRN4/p1581342026046400

@dellagustin: That question is actually in line with something I consider an unsung best practice: Keep a record of a project's history
I just added this weekend a history section to a personal project of mine (a podcast aggregator distributed as a chrome - and soon other browsers - extension): https://github.com/podStation/podStation#history
I was also looking for the opportunity to show my baby 😀
I think it helps people that reach the project to understand why it exist and how it got there.
I would propose that we add this to the list of InnerSource best practices and upstream it to the Open Source community (I am assuming this is not yet a generally agreed best practice):
I would also propose we add a history session to the innersourcecommons.org website. I will create an issue for that.

I accepted driving this topic, so please assign me to this issue if possible.

References

Acceptance Criteria

  • A community-agreed plan
  • An issue(s) that, when finished, will implement the plan.
@rrrutledge
Copy link
Collaborator

So you would add a History section to the README?

@dellagustin-sap
Copy link
Contributor

Hi @rrrutledge I do not know yet, I will fork it and come with a few different proposal for use to compare.
It could be a step by step approach, start with a short section on README, and migrate to a dedicated History page on the website.

What do you think about this approach?

@rrrutledge
Copy link
Collaborator

That will work fine! I am thinking of updating this issue to have the acceptance criteria of producing:

  • A community-agreed plan
  • An issue(s) that, when finished, will implement the plan.

So this issue tracks the investigation/planning of this work rather than tracking its actual completion.

Does that make sense?

@dellagustin
Copy link
Contributor Author

Perfect!

@rrrutledge
Copy link
Collaborator

Sounds great, Guilherme! I have updated the description with this acceptance criteria and assigned to you. Please take a crack at it and let us know when you think you have something.

@dellagustin-sap
Copy link
Contributor

Just as info - I am prioritizing #91 , as I want to have an easy to setup development environment before working on the other issues I am assigned to.

@rrrutledge
Copy link
Collaborator

That totally makes sense!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants