Followup Developer Unconference Meeting:
Meeting Join URL: https://zoom.us/j/407090817
Meeting Date/Time: 27/06/2019 1:00pm (UTC/GMT)
Agenda:
- Welcome.
- Go over previously discussed topics.
- Review topics that were not discussed.
- Add any additional topics.
- Decide on how to proceed with the Developer Unconference.
Meeting at DDF June 2019
Date: 2019-06-12
Time: 08:00 - 10:00 UTC
Discussed Topics:
1: Setting up developers ENV - making it easy ....ONAP
The Good : We have a lot of people out there that can do this.
Whats there means people can get going.
The Bad :
- For new people coming in (new company) it is difficult - they need to do it themselves
- Multiple projects setup together is difficult - nature of a big system.
- Duplication of places issues are recorded.
The things we can Improve :
- Not all projects have readmes - Each project should have one.
- Each project should have an owner - The PTL is the owner
- This info is in info.YML - could do this at a per module level - or down to the level the project thinks this is appropriate
- Need to keep this updated as people move
- Suggestion - Lazy Dog - "Repeated task documented" - question is where to put them -
- Lazy dog per project / by release -- tricky to keep up to date.
- e.g. sharp title - "Error Code title" + workaround (NOTE: Jira will also record it.
2: Tutorial is there - but its out of date.....could there be better tutorials developed.
The Good: Generally existing people can help new people coming
The Bad:
- Tutorials are "Woeful"
- Hard to get started - but once up and running it is OK.
The things we can Improve : "How does it breath".
- We should make a tutorial for developers joining ONAP -
- We need to reference the various info tools, - Owner, info.YML, lazy dogs etc. Top level info to get started
- We could archive old tutorials.
- Important that new people reach out, start participating, and that existing people will support new people ---- big projects can spread on-boarding support around
- Common gain if more people working on similar stuff.
- This is less work than tutorials on everything
- Work on a getting started page - can update existing one.
- Communication policy
- Rocket chat - not widely used by every user
- Discuss list is the official comms forum
- Weekly meeting is primary focus
- Component Tutorials for new developers :
- These are needed, and need to be updated periodically
Message to PTLs that this needs some capacity
3: Project Scheduling + getting adequate coding time
The good :
- ElAlto is helping - giving breathing space
The Bad :
- Dublin development window was very tight
- Late Epic freeze - short coding window
Improvements :
- M0 needs to be M0.
- Be formal about Epics closed at M0 to ensure development time
4: Jira - marking them easy for beginners
List of people you can contact in regards to specific components:
This is gold standard badging: https://bestpractices.coreinfrastructure.org/en/projects/1197?criteria_level=2#changecontrol
- We can move it earlier
- Common labeling convention would help.
5: Unit testing
The Good:
- There are some best practices
The Bad:
- There are a lot of bad tests out there
Improvements :
- Mutation tests - can identify in effective tests
- Coverage on new code - expectation is new code always has effective coverage. This is not enforced in tools, but could be turned on.
Next steps
Book a slot a TSC and feedback a summary of this meeting to them.
Do as a one off for now. & feedback to TSC and PDLs. ACTION : @Gareth Roper to call next meeting
Consider Schedule a monthly "Developers UnMeeting" to follow up on this.
Monthly feedback to TSC and PTLs
Informal for now.
______________________________________________________________
Topics identified in the meeting and for further discussion
______________________________________________________________
- Test ENVs -- "Hello world"ing
- Documentation -- Developer focused
RST format
Old / out of date docs
Wiki maintenance
- Code Review Processes
Variety of these across projects and contributors
See this JIRA TSC-69 - Getting issue details... STATUS
- Sonar Q / Check style
reviewer can not see code coverage easily
enforcement
build in checks - samsung proposal
- Kotlin language - bringing it in
- Reflecting Jira ticket status in Gerrit
- Project developed in a company - and then big code delivery to ONAP
Don't know what business func is being contributed across multiple sub projects. Suddenly big chunks of code appear - community not aware of all activity
- Bring Pairwise testing early - CSIT tests
- Different deployments platforms for testing - OOM and cloudify makes testing difficult (DCAE)
- Do we have a miniature version of DMaap for testing - its very large
- Policy testing wrote their own simulator --- are simulators a solution
- Common library for JSON POJO sims / mocks. An API library for managing common events between systems.