Future plans for the Ubuntu Developer Portal
Discuss the current needs of the Ubuntu Developer Portal, what can be done with Wordpress and what alternative software frameworks could be used isntead.
Blueprint information
- Status:
- Not started
- Approver:
- Jono Bacon
- Priority:
- Undefined
- Drafter:
- Michael Hall
- Direction:
- Needs approval
- Assignee:
- Michael Hall
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
== Wants ==
Multi-language support
Easy staging to production
Easy management of page content
Easy management of site navigation
== Pros/Cons ==
Stick with Wordpress: (0 hours)
PRO: No change in framework required
PRO: Good at controlling spam?
CON: Mutli-language support is lacking or unavailable
CON: Staging to production is difficult and unreliable
CON: Not great security-wise
CON: Would be nice to develop content in bzr branches
PRO/CON: WSIWYG editor <- You can't control what the users are putting in the content(html tags, css & even js)
PRO: Schedulable blog publishing
PRO: Navigation is automatic
CON: Navigation is inflexible
PRO: Does blog functionality quite well.
Re-write in Django:
https:/
https:/
https:/
PRO: Cloud portal already does this: https:/
PRO: Familiar to devs both internally and in the community
PRO: Can tie in the API website directly
CON: Would require development time
PRO: Existing CMS apps can provide multi-language support
Use static-site generator:
PRO: having content available in branches would
make it more open to contributions from engineers
Easy merging from staging to production
Easy to track changes
Easy to link to bugs
We can do merge proposals and code review
We can hook the project up with CI
(sphinx) Translations can very easily be done in LP.
PRO (sphinx): we can also generate PDF, EPUB, single HTML and other formats
PRO (sphinx): Translations never get out of date
PRO (sphinx): we will know about broken links
PRO (sphinx): docs can very easily be packaged
PRO (sphinx): machinery exists for packaging and deployment
CON: transition of links (rewrite map)
CON (sphinx): transition to reStructuredText might take us some time
CON (sphinx): navigation is a bit cumbersome
CON: No search functionnality
dholbach: http://
CON: No dynamic or interactive content
Relies on a variety of external services
which services?
PRO (fenchurch): Translations handled by Django templates
CON: Need theme porting
CON (sphinx): Need to convert content to RST
Work estimate:
sphinx solution
???: massage HTML into RST
3-4 days: prototype navigation + directory structure + translations
1 day: hook up with jenkins
1 day: set up rewrite map for URLs
1 day + X: get everything deployed
Work Items
Work items:
[dholbach] investigate what sphinx' options are wrt navigation: POSTPONED
[dholbach] investigate what sphinx' options are wrt directory trees + translations: POSTPONED
[dholbach] find out if we can use direct HTML in the markup: POSTPONED
[dholbach] find out if we can convert html2rst easily: POSTPONED
[mhall119] Create prototype of full Django replacement: INPROGRESS
[mhall119] Estimate time to convert to Django replacement: TODO
[ya-bo-ng] Estimate time to convert to static django: TODO
