... | @@ -182,5 +182,100 @@ Next steps: |
... | @@ -182,5 +182,100 @@ Next steps: |
|
|
|
|
|
In between: Michael McAndrew talks about sprint planning. Joe Murray suggests on first morning if people have clear ideas of what they want to work on they present so others can potentially join. Throughout the sprint there will be lightning talks and workshops/presentations. We will be balancing between getting things done and sharing knowledge/workshops/learning how to do stuff. Jaap suggest there is a group for newbies to have a somewhat longer workshop on development, training etc.
|
|
In between: Michael McAndrew talks about sprint planning. Joe Murray suggests on first morning if people have clear ideas of what they want to work on they present so others can potentially join. Throughout the sprint there will be lightning talks and workshops/presentations. We will be balancing between getting things done and sharing knowledge/workshops/learning how to do stuff. Jaap suggest there is a group for newbies to have a somewhat longer workshop on development, training etc.
|
|
|
|
|
|
|
|
Report back from the groups:
|
|
|
|
|
|
|
|
##### Joe on Architecture:
|
|
|
|
|
|
|
|
Hard topic into something that can be done in a sprint. One short term action: add 1 unit test as you add them 1 by 1.
|
|
|
|
|
|
|
|
##### Mikey on Dev Process:
|
|
|
|
|
|
|
|
Quite a wide topic. Lots of discussion of how we deal with PR’s, we need to come up with guidance and guidelines. Short term actions:
|
|
|
|
There is a developer training wiki, will be turned into a docs book during the sprint
|
|
|
|
|
|
|
|
##### Nic on UI/UX:
|
|
|
|
|
|
|
|
Lots of post-its, what can we do with the front-end - back-end, lots of things we can do in the sprint.
|
|
|
|
|
|
|
|
##### Marco on Community:
|
|
|
|
|
|
|
|
We dropped a lot of tickets to marketing, thanks for taking them! Short term actions: mostly documentation stuff or make people aware of where to find stuff. We put a lot of stuff into long-term where we were not clear on what was meant.
|
|
|
|
|
|
|
|
##### Patrick on Core Development:
|
|
|
|
|
|
|
|
Common theme was LEXIM. Lot of tickets about getting rid of stuff and moving them to extensions. For example get rid of Flash stuff. A few improvements to guide people into doing more documentation like add mkdocs automatically with civix. Also some tickets we did not understand.
|
|
|
|
|
|
|
|
##### Björn on Extensions:
|
|
|
|
|
|
|
|
Some stuff was really easy. Like Shoreditch should be approved, is done. Lots of tickets about process and documentation. Some of us are going to do some prototyping during the sprint. Also lots feature requests, all in there but will not happen tomorrow.
|
|
|
|
|
|
|
|
##### Detlev on Marketing:
|
|
|
|
|
|
|
|
Main thing was core website which has a number of issues. We have no SEO -> short term action. We need to add the privacy/secure/autonomy stuff to our website, this can be added. Detlev will do this. We did not complete the list, as a group we will meet again today to go through the list and see if we can complete it for short term actions.
|
|
|
|
|
|
|
|
|
|
|
|
### Establishment Committee - next steps
|
|
|
|
|
|
|
|
- Alice spoke about what governance means and how the term is loaded and perhaps not should be used with respect to the establishment community. What we’re trying to do is develop a way to manage ourselves as a community and how we move forward.
|
|
|
|
- A challenge within our community is that most of our communication is digital, which de-emphasizes the non-verbal aspects of communication.
|
|
|
|
- The remit from the NJ summit stemmed from conflict. Our remit from this year’s summit is more positive and more focus on what we can do to grow and to improve.
|
|
|
|
- The remit of the elected body is to study and recommend a few methods of how to move the community forward and to address conflict management.
|
|
|
|
- A large part of the reason why we’re here is to address conflict management both on a person to person level as well as at the larger community level.
|
|
|
|
- Aidan provided an update on how the election process will take place.
|
|
|
|
- Guy raised the point about defining what the community council is trying to solve and how that will affect who runs and is elective. Part of the role of the community council is to help define these priorities.
|
|
|
|
- The group discussed the role of and reasons behind the elected committee and what its mandate should be.
|
|
|
|
|
|
|
|
### Sustainability
|
|
|
|
|
|
|
|
- Financially the core team is stable, however its small and under resourced. If we’re ok with this, then we can continue. If, however, we want to change and try things, then we as a community need to figure out how that impacts sustainability both financially as well as from a resource perspective.
|
|
|
|
- The CT is now again being paid for the hours they work. Could we squeeze more out of them? A little bit but not a lot. We could potentially get 25% more out of Tim, Coleman is full time.
|
|
|
|
If we want to increase the speed of delivering Form Builder we will need more money.
|
|
|
|
- Sergey: we should invest more in advertising and resources.
|
|
|
|
Olly: can we fund someone “less senior” to take stuff over from Tim which would free him up more. Josh: we need more money then. Olly: increase partner fees by 10% (hear hear from Joe, Detlev and Erik)
|
|
|
|
Roshani: we have to make sure that we make it prettier but we also need to make sure that partners are actually available to help new customers otherwise it makes no sense
|
|
|
|
- Detlev: at the moment we are not ugly enough but we need to do stuff now to make sure we are not too ugly in a few years. We need to invest in a bigger community because we need the additional hands to do all of the work if we do get 1000 more customers.
|
|
|
|
- Björn/William: marketing should be done by partners.
|
|
|
|
Mikey: split responsibility, we have to make sure that regionally our stuff is under control
|
|
|
|
- Erik/Joe/Parvez: we do a lot of marketing according to the pull mechanism
|
|
|
|
- Roshani: should we then not do more marketing to developers
|
|
|
|
- Tim: I am trying to understand the tension between we want more marketing but we can not handle more work
|
|
|
|
- Joe: I want the community to do better at removing technical debt etc. so I want to grow the community. If we have more developers we can move quicker.
|
|
|
|
- Jaap: Mikey said we should be in markets: we assume we are one, we are not. We are a random community. So where does the ‘we’ fit in? Mikey: the we is the brand, the CiviCRM logo. Our common mission is to ensure that everyone hears about CiviCRM.
|
|
|
|
- Eileen: WMF has a mission statement that says that the sum of all human knowledge should be available to everyone in the world. Should we have a statement like that?
|
|
|
|
- Bruce: so we want to create more competitors? That sounds weird. But we need to have this standard branding.
|
|
|
|
- Sergiy: it is about branding, for example: how are we going to introduce the brand into Africa?
|
|
|
|
- Joe: I have tried Africa but I felt really bad about my rate. We need to find local people who can help them locally.
|
|
|
|
- Francesco: I am new but it is very difficult to imagine brand marketing around CiviCRM globally. The countries are different. Real marketing like advertising et. needs to be done in the countries and by the partners. Also it would have to focus on market areas like fundraising for example. Also all around the world what we could imagine is something like comparative marketing. Perhaps we can spend money/time//resources to set up free prototypes in new countries.
|
|
|
|
- Alejandro: some time ago we had a marketing team and we hired an agency. We did a booth kit and we had some central stuff. My lessons learned: this has to be done regionally. Make concrete small actions. Is there someone who wants to take the lead in this marketing group?
|
|
|
|
- Nic: would it be an idea to say this is our budget and ask folks for suggestions what do we want to do with it.
|
|
|
|
- Alejandro: I like the concrete actions and a group that can start doing things.
|
|
|
|
- Guy: good ideas. If you follow the thread about the logo…...someone does something and then gets lots of feedback. We should learn to just let someone do something and then accept that they take a decision.
|
|
|
|
|
|
|
|
### Paid extension ecosystem
|
|
|
|
|
|
|
|
- Matt: we do not want it like Worpress. Some of the extensions just need to work and we need to come up with support so that they do work. Some of the extensions need to work but do not immediately stop the process so the customers might not want to pay for that immediately. So where does that money come from? So could there be a generic way in which customers know they can get support?
|
|
|
|
- Seamus: so how do we declare that an extension is still maintainable?
|
|
|
|
- Mikey: we need a mechanism to say that an extension is a security risk and we are not going to fix it.
|
|
|
|
- Parvez: being able to contribute to maintaining an extension. Mosaico as an example: it has the capability to make a lot of money. We are not exploring this revenue stream. This could all go to core. But also us: we do not want to manage our extension, we want it maintained by the community. I think it should be one rule for all.
|
|
|
|
- Joe: did you figure out some of the hows of the finance? I do not like the idea of everything going to core because it takes the responsibility/moral obligation away from the developer. I do not want the effect of people giving up on their extensions.
|
|
|
|
- Sergiy: I like the idea, I would like to pay to know that it works and is certified.
|
|
|
|
- Jamie: PTP has a different motivation. Our ambition is to support orgs in the states. So if you ask us to maintain an extension it is not where our aim is. Nor do we want money, we would rather not have money but just do it as our contribution to the community.
|
|
|
|
- Bgm: as a service provider sometimes doing support we sometimes fix extensions Are you Matt trying to find a better system for non-profits to pay for bug fixes?
|
|
|
|
- Parvez: the conversation is moving towards paid support, I think I was thinking about donating to support
|
|
|
|
- Mikey: I hate the word paid extension, I get the Wordpress experience. It is the worst kind of messaging. What we are discussing here is different and feels OK. But we do not do code reviews or security reviews. So we first need to solve some fundamental problems with our extension system. We can not yet think of paid extensions if we do not first improve our extension system.
|
|
|
|
- Parvez: can we make this an opportunity to make some of that happen?
|
|
|
|
- Rebecca: if we make it payable you increase the expectation.
|
|
|
|
- Guy: we need to be clear about the problem we are trying to fix. We want people to put quality software into the system whilst knowing they can get some money to maintain it. The idea then was to have different levels of publishing extensions: if on the UI there has to be a review and if just on Gitlab: use at your own risk.
|
|
|
|
- Olly: request of paid support, I have no idea what that means. It implies that people can pay now and then someone leaves the community?
|
|
|
|
- Tim: we are trying to lower the bar for a user to get support. So perhaps we can just communicate better what the support is. This could be that a single developer is willing to accept payment to support, some which are social things where groups are happy to support and some just want to share what they have done.
|
|
|
|
- Mikey: I like the idea of telling the user what the support is
|
|
|
|
- Björn: what do we actually mean with support? Is it just security patches or is it bug fixing, is it making sure it works with the new version? That to me is confusing in combination with 4 different support levels. I quite like the just send me an email because I know what is going on. Instead of creating this elaborate process just explain what the model is and who can I contact to get it fixed?
|
|
|
|
- Michael: a minimal stability level, so if a person willingly chooses the wild wild west it is fine.
|
|
|
|
- Eileen: it is a high overhead to ask the core team to do this - ie charging money for small but often vague pieces of work is likely going to incur a lot of admin. At the moment key extensions are not controlled by the core. Shoreditch is an example where Compucorp wants to remain control. If core / the product maintenance team has ultimate responsibility for maintaining an extension it must have the control to do so and that responsibility is implied if support is offered / administered via core.
|
|
|
|
- Jaap: Civirules as an example: we want to share it. We want to take on some responsibility but not all of that. At the same time we feel proud enough to keep maintaining it but we accept PR’s a lot. We as CiviCooP fund a week each year to fix stuff in CiviRules. We are happy to share but we do not want to take the responsibility.
|
|
|
|
- Joe: I’d like to come back on a future day and continue to conversation. First: it is unclear what kind of support they are agreeing to. I like the idea of the CT making some money out of this somehow but I want to figure out where the responsibility lies. I’d like to continue the conversation.
|
|
|
|
- Olly: could a couple of people write up what has been discussed and what should happen? Guy, Matt to discuss further tomorrow.
|
|
|
|
|
|
|
|
## And, it's a wrap!
|
|
|
|
|
|
|
|
Thanks to everyone for coming, to our sponsors, and to everyone that makes CiviCRM possible. The feeling from this summit is positive and forward looking, and the atmosphere has been very good. Olly put out a request for feedback about what worked for this summit and responses were very positive. |