Difference between revisions of "5.1 Roadmap"
(→Minor goals) |
(→Project governance) |
||
Line 29: | Line 29: | ||
* http://oss-watch.ac.uk/resources/governancemodels | * http://oss-watch.ac.uk/resources/governancemodels | ||
* https://opensource.guide/leadership-and-governance | * https://opensource.guide/leadership-and-governance | ||
+ | |||
+ | '''Decision:''' | ||
+ | |||
+ | We will continue with the benevolent dictator model. The Architect will define the project's strategic direction and have the final say in decisions. However, if a contributor regards a decision as unfair or contrary to the projects goals, an appeal can be made to the Administrator. | ||
+ | |||
+ | The current Architect and Administrator are listed on the wiki Team page: | ||
+ | |||
+ | * https://gramps-project.org/wiki/index.php/Team | ||
===Procedures for branch merging=== | ===Procedures for branch merging=== |
Revision as of 19:36, 4 March 2019
This page collects possibilities for the 5.1 version of Gramps
Contents
Schedule
31 Dec 2018 | Agree final roadmap (this document). |
15 Apr 2019 | All major features should be merged into master. |
15 May 2019 | Feature freeze. |
01 Jun 2019 | String freeze. |
15 Jun 2019 | Final release. |
Policy changes
Project governance
At present, we use a benevolent dictator model. The BD defines the project's strategic direction and has the final say in decisions. Do we wish to change this?
Do we want to introduce a voting process for significant changes? If so, who gets a vote?
Perhaps we should introduce a committee to make decisions?
The following web pages are worth reading:
- http://oss-watch.ac.uk/resources/governancemodels
- https://opensource.guide/leadership-and-governance
Decision:
We will continue with the benevolent dictator model. The Architect will define the project's strategic direction and have the final say in decisions. However, if a contributor regards a decision as unfair or contrary to the projects goals, an appeal can be made to the Administrator.
The current Architect and Administrator are listed on the wiki Team page:
Procedures for branch merging
Currently the core gramps50 branch is occasionally merged into master. This process seems to have been a success, but we need to review it.
Do we want to extend it to the addons repositories?
Who should merge the branches?
When should they be merged?
Pull requests for significant changes
Always using pull requests for most changes has been proposed previously and rejected [1], but we can discuss it again.
What changes should require a pull request?
Who should be allowed to merge a PR?
Should the submitter be allowed to merge the PR?
How long should a PR remain open for reviews, comments and testing before merging?
Dependency upgrades
- Python 3.5.x[2] (as 3.3.x reached end of life status on 2017-09-29.)
- Gtk 3.12.x EmailIt looks like we should just move from 3.10 to 3.12 then. Nick. (3.10.x reached end of life status on 2014-05-12.)
Database model changes
Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here.
- Enhancements to the place structure to support GEDCOM-L PLAC tag
- Allow multiple place Types with date for each
- Deal with 200+ place types
- Allow multiple postal codes and other attribute like data, with date for each
- Allow places to have attributes (for above)
Suggested changes to implement the requirements above:
- PlaceName
- Add a list of PlaceAbbrev objects. A PlaceAbbrev object should consist of a some text and associated type (PlaceAbbrevType).
- Add a citation list.
- PlaceRef
- Add a hierarchy type.
- Add a citation list.
- Place
- Replace the place type field with a list of LocationType objects. A LocationType object should consist of a date, PlaceType, and citation list.
- Add an attribute list.
- Add an event reference list.
Major goals
This section lists main goals developers want to achieve. Major goals should be started in a GEPS branch. Major goals require a developer and a reviewer.
- GEPS043 Improving GEDCOM support for Places
- GEPS044 Rewrite UIManager code to avoid using deprecated methods
- Store objects as JSON rather than pickled blobs See feature request #9392. Previously discussed on the list. [3]
- Remove raw methods from database API
Minor goals
This section lists minor goals developers want to achieve. Minor goals can be done by one developer alone.
Suggestions:
- Some "attributes" we have currently don't match up well with GEDCOM When Gramps originally was conceived, these attributes did not have dates, places, and media attached (Gedcom did not have these either). The last version of GEDCOM allow this. Dated attribute would help, or just make these into Event/Fact types.
- A method to mark objects as "used" TODO tagged items work like this now, maybe another standard tag?
- A way to attach objects to the database itself Something like the "Researcher"/"Database owner" but including other data. See 6365 & 8734
- Recommend SQLite3 (as default) for all users [4]
- Change location of resource-path file to allow Python pip Wheels. eg: Running a post-install script is not possible with wheels, so it looks like we need another approach. I suggest that we look for the resources in the standard places at run-time. - Nick Hall & Re: (Gramps-devel) tar files, zip files, distutils, etc.
- 6300: Organize Tags be able to select a background color also for visability - This would be quite easy to do, but would require a database change. - Nick H
- 10777 Fulltext search on all elements, objects, items, types which can have a text / string in.
- Support Gedcom _UUID. Two choices 1) extend data model with a list of additional IDs, which would be _UUID or possibly GOVID, GEONamesID etc. 2) Store them in attributes. The former has advantage that they are invisible to users except for tools explicitly using them, also could easily support db lookup like GrampsID. The latter limits work to import/export. Gedcom L group has just completed a vote on how they should work for import/export. Ultimate goal, better merging.
Rejected: