---------------------------------------------------------------------------
This is a shared scratch pad/note taking area created for the Plone planning & organising sprint held at Amterdam, The Netherlands from july 30th to august 1st. 

These are not finished guidelines, proposals or whatever definitive things, but live minutes to help with discussing various planning and organising issues, problems, ideas and tasks for the Plone Community. 

Present at the sprint location in Amsterdam:
Additional Remote Sprinters that was present at some time:
---------------------------------------------------------------------------------------------------------
P&O Sprint saturday july 31st. Make a more extensive list of non programming tasks
that we could do this weekend, also so that remote sprinters can pick smaller tasks. Loosely
followed from the topics written on the sprint page at coactivate.

Non developer/programming tasks that could be done 

planning, what could we do today/saturday/tomorrow? 
-------------------------------
P&O sprint friday morning 30-07, listing of all teams




Plone teams (both 'formal' and informal):


Plone Domains in use

Tasks that are unassigned or where the process is unclear

* response and coordination of bug reports (non-criticals, non-security relevant) for all Plone packages.
* managing incoming pull requests (non-PLIPables)


Documentation gaps:
List of persona's/ target groups so we are using the same (temporary) definitions during the discussions/brainstorming:

----------------------------------------------------------------------------------------
P&O Sprint friday 30th july afternoon. listing of target groups/umfeld for which the plone community creates software/information/value. 

We found out that we sometimes mean different things under the same name, for example what an integrator or a solutions provider is. So we created this list to avoid misunderstandings during the sprint. 


Decision Maker
- I need an Information system to solve a problem.  Can I use Plone for That? 
-> features 
-> description of how Plone is developped and can be used 

A deicision maker could/might turn into: 

----------------------

Plone end user:
- use a provided Plone system 

Plone Administrator
- Webmaster, have through the web manage access 
-  Configure Add'ons 
- help end users with using Plone 

Plone integrator: someone who knows how to:
- Administrator 
- install Plone 
- Configure/webmaster plone 
- Add some add'ons and use them 

Plone themer:
- customise Plone  Look and Feel 
- knows a bit about the development process 

Plone developer
- integrator + 
- Develop plone-add'ons, do custom code modification 
- Work on Plone Core 

Plone solution provider:
- Sell integrator and/or developer and/or theming services to other internal or external customers.  


-------------------------------------------------------------------------------
Friday afternoon july 30th:
Are these persona's / target groups happy at the moment or not and why? We do this to identify things that are missing for these persona's?
-------------


Try to write down a processes to get a feeling for them. 

Release Process (bugfix release 5.0.X) 
What's not in the current proces: 
semver versioning. bugfix releases should not contain any functionality changes. 
minor release could contain functional changes/additions 

---------

Release Process  (Minor Release)  5.1) 
What should be added compared to the bugfix release 
Try to come up with mechanisms to sync these involvements? Can the documentation stop a PLIP if the docs are missing? can the release manager release a minor version if the press release is not ready? 



Major releases: (Plone 6)

---------
On saturday we found out these proceses are in some form written down in release notes in the github repository of the buildout.coredev account at https://github.com/plone/buildout.coredev/blob/5.1/docs/release.rst , but this much more an extensive technical checklist and some of the interactions from/to other teams are missing. (which could be a cause of some of the quality control issues we have). 

The Framework Team's PLIP process is written down quite extensive on Plone.org, (link needed here, it was shown), but parts of it seem not be be followed anymore. 


------------------------------------------------------------------------------------------------
Written by a remote contributor friday/saturday july 30/31st. . Is this a 'should be' process, or an 'as is' process? Or a mix?


Roadmap process
- never written down.
- seems to involve having a confernce. having a discussion. Listing out what everyone has on their minds as features/major changes they would like to see or neccessary based on their own ideas.

One way it could work. Based on idea that we can be all things to everyone eventually but there is a limited amount of resources and some activities will help a community achieve its goals quicker than others.

1. Pick a vision of the community in 2020. How popular. specific numbers for each of the defined user types. Not what Plone he product will look like but what the community will look like.
2. Determine which users types need to be targeted first to achieve this goal. This is the most strategic part. For example, should integrators be the most important because they will choose the technology and end users often don't get a say? Should core developers be put first, since without them development will stop and everyone else will suffer?
3. Take the list of features/ideas/changes, For each feature determine which user type is affected and how they are affected using these categories. 
   - [wow] Something this user might switch to plone for. A USP. Something that demos well or makes a good headline. There won't be many of these.
   - [doh] Something competitors have for that user type, that we don't have and its a deal breaker.
   - [tick] Features that aren't used so otten but are normally on lists of things when decision makers and evaluating products and could negatively affect the decision to buy
   - [smooth] features that are harder to describe or sell but make it easier to use. Things users can only appreciate once they are a user but will help in them recommending the product to others. Reduces support queries
   - [power] features that you have to be a deep power user appreciate but can help those users enormously. There is normally a harder existing way to achieve this.
   - [scale] features that increase performace or help with problems encountered when you run a very big site, or lots of sites.
 4. Determine a priority of feature categories to achieve your goals. If community growth is the goal then it should probably be in the order above.
 5. Sort the lst of features. Promote and publizes the priority order in the community. Help use that priority order to determine which sprints to make strategic.
 6. Brainstorm missing features that fall into those categories.  

At the end of this you will have a proper roadmap listed in priority order. Which is not to say thats how it will happen in reality, but at least everyone will know what the joint goal is and what the strategy is to get there.


----------------------------------------------------------------
Plone community processes continued discussion saturday morning:

Generation of new features process
- PLIPs are toward the end of this process. Where does it start?
- Maybe it should be documented


---------------------------------------
P&O Sprint friday morning 30th july. After creating the list of teams, what are the tasks that we currently know of that these teams are doing?

What is every team doing officially and unoffially?

Difficulties here: 
-> What were they doing, what are they doing, what should they doing, what do we think they are doing?
-> We should validate this list in some way.

Plone Board:
Membership committee:
* Evaluate new member applications
* Recommends membership to the board


Framework Team:
* Evaluate and vote on PLIP's (PLone Improvement Proposals).
* Coach PLIP proposers to improve PLIP documents before they are accepted.
* Delegate proposer to other teams like UI/UX or Documentation.
* Review PLIPs with heavy impact on Plone
* Decide when to include a PLIP (Major, Minor, Bugix) - stick to semantic versioning as good as possible.
* Technically Merge the PLIP branch into the code repository
* PLIP process documented here: http://docs.plone.org/develop/coredev/docs/plips.html
* Discuss incoming Pull Requests if they need to go through PLIP process or not.
* push release manager to do releases, coordinate releases with PLIP merges. 
* coordinate with release manager to cut new branches for Plones next minor/major releases (this is the most complex task and needs coordination with testing team and documentation team, the exact process of this is not defined).
* helps release manager with new-features list on major releases

Training Team:
* Developing training material
* Organising the PloneConf Training days

Communication Team aka Marketing Team:
* Manage  Plone social media accounts
* Write Press releases
* Create Physical Marketing Material  (Tshirts, flyers, posters, booklets )
* Write Plone.com content

Documentation Team:
* Manage docs.plone.org technical setup
* Managing the release of Documentation Versions
* Writing guidelines on how the documentation should be written
* Documentation Quality Control
* Advise on Documentation Present


Installer Team:
* Create the universal Installers for Plone
* Maintain Docker/Vagrant setups for Plone
* Ansible playbooks? 

Testing Team:
* manage the testing software servers (Jenkins Server),
* Give guidelines on what testing software should be used, best practices

Release Team:
* Release and push all the software packages on pypi that comprise Plone the Product
    * Tags on github for each repository of the plone core packages
    * Managing the coredev buildouts
* Coordinate with or assume the duties of the Launch Team?

Security Team:
* Issue patches for security issue in Plone
* Evaluate incoming Security issues/ Bug reports
* Do code evaulation on Plone Core and 'selected' add'ons
    -> (which add'ons are 'selected?)

Admin and Infrastructure (AI)-Team: 
* Manage Plone Infrastructure, the servers on which the official sites run
* the mailinglists.
* RC-Channels. 
* community.plone.org software install & updates


I18n Team:
* manage plone.app.locales
* manage Transifex account (?)

Usability Team (formar aka UX team):
* Design and decide on end user experience of Plone the product
-> Both Visual and Textual
-> Some overlap with accessibility Team
* Audit the Official Plone theme (Barceloneta)  for responsiveness, mobile, browser Support
djay: deciding end user experience effectively means deciding on features and its not clear how that works in practice. Plips are done by those that care. How can the UX team tell people what to do? More thought needs to be put into roadmap, features and how stuff really gets decided in plone to come up with something more pragmatic. 

Accessibility Team:
* Audit Plone for accessibility Issues
* Maintain a resource list on Accessibilty documentation & best practices

Plone.org Team:
did:
* design the new plone.org visual theme and features
does:
* Develop functionality for the plone.org website
* Writes some of the 'framework' content that doesn't change
* structuring of the content
-> Most of the content should be community generated
Partly efforts are ad-hoc. / Overlap with documentation team

Plone.com Team:
* Was an adhoc team to create the new plone.com website. 
* Mostly merged with the Marketing Team
* Develop functionality for the plone.com website

Launch Team: (adhoc, not really a team, trying to bundle other teams)
* Coordinate docs, training, marketing, and release of software    

Ploneconf "Team"
* 

=====================
Brainstorm Stuff:

Teams we should have:
* Onboarding team
* history-team
* Process troll team (we are!!!)


--------------

Who is managing?
* The Slack channel? (Kim, Jean Jordaan)
* Planet.plone.org? (that's clear: it's a github repository, just open a pull request to have your blog added)
* paragon (once we have the new add-on thing going, it can go to the big /dev/null in the sky)
* ploneconf.org and subdomains (AI team)
* plonesymp.org and subdomains (AI team?)
* YouTube Plone channel?


-----------
Saturday afternoon, discussion on the add'ons story (aka paragon, aka PSC replacement)

How to find add'on on plone.org
* only link is in doormat on the start page (https://pypi.python.org/pypi?:action=browse&c=589)
* the big blue 'add-ons' text below the hero banner isn't clickable ...

The link in the doormat links to pypi, but the pypi trove classifiers cannot discriminate between core plone packages, buildout or framework/testing packages and 'real' user addable add'ons. 
We might need an extra trove classifier for 'genuine' Plone product add'ons.

then you can search for :

Framework :: Plone :: AddOn
&& (union)
Framework :: Plone :: 5.0

Or we could use an existing general trove classifier like: "Environment :: Plugins" .   All classifiers: https://pypi.python.org/pypi?%3Aaction=list_classifiers

Other useful trove classifiers:
Development Status :: 5 - Production/Stable

We have to ask all plugin releasers to add the Plugins classifier to their pypi packages.
* You have to put it in the setup.py
* It's possible for owners to add classifiers on already released packages as well.
* Add the classifier to bobtemplates

Ask for warehouse to be able to AND trove classifiers. Warehouse already looks much nicer. 

Support curated lists? Can we add hand picked ad'ons on top of the pypi trove classified full list?

ideas behind orginal paragon:
- opionated. not have a public voting on popularity
- not be exhaustive, max 50-60
- to specifically not include low level developer add'ons.
- add tags for classification
- entry barrier: README, some documentation
- bonus points for including screenshots and other meta info when submitting an add'on

Target groups for paragon info:

* Newbie Plone administrators/integrators that want to test/add some add'ons to their Plone site for the first time. This should be as seamless as possible.

* Long time Plone users that come back to Plone in a new version and are looking for 'new' Add'ons to extend their site.

KISS principle? Start with a normal Plone page where we list the add'ons?  Already is there but doesn't work, cannot present information like Plone  versions. and tags/categories.

------------------------------------------------------
We probably want curated tags. Have some selected 'categories' as tags. 
Add minor single dot versions. 4.3, 5.0, 5.1 
name of the package 
nice description

* Should descriptions be pulled from the pypi information or be hand crafted/separate and editable. <> Then you can ask a copywriter to improve the description.
* Pull other info from pypi like docs link etc. Alexander will look into this

----------
Create a page that can dynamically pulls in a list of add'on packages from pypi and put it in a datatable of some kind with pagination and selectable classifiers. 

djay: alternative is using automated phone home system to get stats on what is used in production and what is compatible with which plone version. Helps add tags to plugins on plone.org on which is plone 5 compatible.
Another alternative would be phone home system in travis builds to record when a plugin passes for plone version X and display that as a tag on plone.org.
- idea is to not rely so much on individual 



-----------------------------------------------------------------------------------------
P&O Sprint saturday afternoon july 31st. 

Discussion of the plone.org download and hotfix pages.  (see task list at the top of this doc)


Plone.org downloads page  & download directions on the homepage
homepage

* 'Older releases' directly throws you off the Plone site to launchpad. It should link to a subpage (probably downloads page) where we have an 'older releases' section where we explain why you might need to download Plone instead of the preferred Plone 5.

* The download page has two similar Call to Action buttons for Both Plone 5 and Plone 4. We want prospects to download Plone 5!. We should move the 4.3 button down the page to a separate section where we explain why people would want to try out Plone 4.3 (Because their organisation still uses Plone 4.3 sites and they want to experiment.

Below the Plone 5 button we can put a line with a link to the 4.3 section. 

* Link to the plone-announce mailinglist. Can we also add a @plone-announce twitter account where officeal release and security announcements are made? 

For end/first time users it might be confusing and scare them to have big hotfix banners on the download page where they haven't even installed the product yet. And we could make these banners dynamix because we know when a hotfix is needed for which release. -> Alexander will look at this, Installer team will discuss releasing updated installers when bugfixes come in so latest 'stable' and 'oldstable' have all relevant hotfixes included.

Another idea: it's not that hard to add hotfix releases to the universal installer, then we don't need these warning on the most recents (supported) Universal installer downloads at all. -> see one paragraph up

If you think of three Plone target groups/persona's like 
* newbies, want to try out plone
* beginning/intermediate user, is there an update for my system
* expert user, I install Plone form source.

And then look at the downloads/hotfix pages, sometimes one of these persona's is undervalued/not catered for. Many pages have little newbie info or guidance, and are overly complex.