Github folder/file structure

panosc-eu / panosc

The main repository for common issues and general information about the PaNOSC project sponsored by the EU

Apache License 2.0

17 stars 46 forks source link

Github folder/file structure #2

Closed JBodera closed 5 years ago

JBodera commented 5 years ago

Hi,

I am starting to prepare the basic bits to manage and coordinate the project, and I would like to propose the following structure to store and manage the documentation in GitHub:

My idea would be that each WP leader is responsible for the structure of his/her area, however many will have access and will be able to update/create content. ESRF will be responsible for the structure in Submitted Deliverables, as I believe we need to upload the documents, even when others will be in charge of creating them on time.

GitHub will be doing the version control for us, so we can know who updated what and when.

What are your thoughts? Any feedback is welcome about the suggested structure and about whether using GitHub or not for stuff that is not code.

andygotz commented 5 years ago

Thanks Jordi for the proposal. Here are some comments from my side:

are the numbers going to be part of the directory names?
what is meant by Plans. Maybe replace this with Planning
do we need an Issues directory? The issues could be managed on github.
I am not sure we need the pre-project directory. I would move the agreements to a single directory Agreement in Project.
rename Submitted Deliverables to Deliverables
not sure we need Post Project. Can be added later if necessary.

We are an Open Source project in github i.e. all documents are open to the public. This includes the grant and consortium agreements. That is not a problem for me but we should be aware of this and all participants should agree to this openness.

Andy

JBodera commented 5 years ago

Hi Andy,

The numbers are to show the order, but are not needed.
By Plans I mean any document related to planning that we do. An example would be a Gantt chart with all the deliverables, but could be anything else related to Planning (e.g. we do not have a detailed plan for any of the work packages or if we need to build a plan to deal with an exceptional circumstance)
True. we can use that feature of GitHub
Pre-project is just for clarity, to show that the contents relate to pre-project work and to clearly separate them from the project deliverables
The "Submitted" part of the name is to highlight that this is just a snapshot of what we are providing, not for work in progress (that would be in the respective work package folder). However I do not mind about the name.
True, post-project is not require anytime soon.