Open dellagustin opened 3 years ago
This is an interesting angle to make it easier to reuse the project and contribute to it.
Some other ideas where customizability could be helpful:
https://yourcompany.corp/innersource-instructions
by default right now.@spier https://github.com/SAP/project-portal-for-innersource/issues/26#issuecomment-877785826 all good considerations.
I'm thinking about how I'd like the experience to be from a developer's perspective reusing the portal. I am picturing something like this:
npm init
npm install --save @sap/project-portal-for-innersource
depending on how we do it, could be --save-dev
npm start
or build it for deployment with (it would output something deployable to the dist
folder)
npm run build
portal-config.json
A suggestion for the portability:
Rename repos.json
to repos.sample.json
and add repos.json
to .gitignore
, update the README.md with the extra step of cp repos.sample.json repos.json
That way if the sample data gets updated I don't get merge conflicts when I pull from upstream.
👋 One thing I've done to customize the portal for a few companies is to insert any "Overview metrics" right at the top just above the search bar and filters. This is done through a nightly automation to keep the stats fresh.
Example:
"424 InnerSource repositories, 10% of all repositories, 21hr average time to first response on Pull requests, Average security score: 90"
Hi @svrnm, this is an interesting suggestion. I'll discuss it with @Michadelic.
@zkoppert , that's an interesting customization, thanks for sharing!
thanks @dellagustin
Amazing list of suggestions to customize the portal. Thank you so much for bringing these ideas together and the discussion here in this thread. I will have a look and i am also very open for public contributions on this issue. Maybe we can jointly create a concept and work on it.
My two cents for getting it implemented:
config.json
file as @dellagustin-sap suggested in the root directory and adjust the portal so that it reads the config file instead of hard-coded values in the portal. Then the config file can be updated at any time to adjust the beahvior and content of the portalnpm init
command to fill the config.json file interactively by asking with the comments defined in the config.json file. This would need a json format that supports comments or a separate file for the wizard. The wizard can also be used to update existing values at any time and readjust the portal behavior.We could start with the config.json file and the list of suggestions in this thread and later add the wizard.
What do you thing?
PS: the overview metrics is also an interesting idea. This would probably done in the crawler at the end and update an entry in the config.json
file?
Having a configuration to fill out the page details is a great idea! It also helps to find all the things that need to be changed since on the HTML page they are at very different places 👍
A few other suggestions:
npm
is currently only used for pulling in some dependencies via the postinstall
and then it uses http-server, so it is possible to run the portal without npm and with my "preferred" (or available) webserver, for example I can just do php -S localhost:8080
and it works, or I can put it into a nginx container, or I can use GitHub Pages (see below)! It would be great to have those alternatives documented.making peoples' live extra easy the name of the folder could be docs/
, because this is the only other path GH allows besides /
:
Here is a prototype how this could look like: https://svrnm.github.io/project-portal-for-innersource/#display=card
As mentioned on the the ISC Community Call InnerSource and Discoverability, one of our ideas for the portal is to make it customizeable.
What is the problem?
Currently, the way to reuse the portal is to fork it and modify it, it is not reusable in the sense of being a customizeable dependency that can be reused without modifications.
One of the cons of this approach is that it is harder to keep it up to integrate updates, as there may be conflicts between the changes on the original repo and the forks.
Here are some of the features that could be customizeable:
What is this issue about
I created this issue to collect ideas on how we could make the portal customizeable.
Features we should keep
One of the great features of the portal today is that it can be easily hosted as static files. This make it easy to operate, as it can be hosted for instance on GitHub pages. When making customizeable, we should aim to keep it for simplicity.