Meetings/20140114: Difference between revisions

From diaspora* project wiki
(+other meetings)
 
(9 intermediate revisions by 6 users not shown)
Line 3: Line 3:
Thoughts on the release process? Do we want to schedule releases? How often do we want to release?
Thoughts on the release process? Do we want to schedule releases? How often do we want to release?


=== Milestones ===
=== Issues on github ===
 
==== Milestones ====
Fla: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target".
Fla: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target".


Line 11: Line 13:
* [https://github.com/diaspora/diaspora/issues/4264 #4264 youtube embedding broken]
* [https://github.com/diaspora/diaspora/issues/4264 #4264 youtube embedding broken]
* [https://github.com/diaspora/diaspora/issues/4683 #4683 correctly strip HTML and Markdown]
* [https://github.com/diaspora/diaspora/issues/4683 #4683 correctly strip HTML and Markdown]
* [https://github.com/diaspora/diaspora/issues/4269 #4269 Comments are out of order]
==== Clean up issues ====
* Read some old issues, starting with the [https://github.com/diaspora/diaspora/issues?direction=asc&page=1&sort=updated&state=open least recently updated ones].
* Check if the bug still exists, if some more information is needed and if the issue is suitable for newcomers.
* If it is an important or easy to fix issue: decide if we want to add it to a milestone / promote it in a bugmash monday
These tasks can be done by a non-technical person, so we can call for contributors, we only need people on pods using the develop branch.


=== Improve podmin's life ===
=== Improve podmin's life ===
Line 29: Line 39:
=== Spammer accounts ===
=== Spammer accounts ===
Recently more spam has been appearing on Diaspora pods. Some things are already being fixed like [https://github.com/diaspora/diaspora/pull/4626 Captcha support] which should land soon in develop. Other things we should do to combat spam?
Recently more spam has been appearing on Diaspora pods. Some things are already being fixed like [https://github.com/diaspora/diaspora/pull/4626 Captcha support] which should land soon in develop. Other things we should do to combat spam?
=== Press stuff ===
A hosting company recently sent this to the press team, promising "diaspora hosting for as low as $4/mo" in a shared hosting environment. They are basically making (afaict) non-valid promises using the Diaspora official branding (see included url).
<ol><pre>Hello Sean,
I noticed that you are the community manager so I wanted to reach out directly. Please let me know if there is someone else I should contact to discuss further.
My name is Gregg Hawkins and I'm the marketing manager for Arvixe, a web hosting company. I wanted to inquire about becoming a recommended hosting provider to the visitors of your website. I have created a landing page, which can be found here: http://www.arvixe.com/diaspora-hosting
More specifically, I'm wondering what it would take for you to create a tab on your website that says "Web Hosting" and on that page simply put a paragraph introducing Arvixe and then linking to us?
I'll be looking forward to a positive response!
Regards,
Gregg Hawkins
Marketing Operations Officer
</pre></ol>
How shall we respond?


== What did we decide? ==
== What did we decide? ==
=== Release process ===
* We won't commit to a release cycle with a new release within a set time period.
* We'll decide at each monthly meeting whether we are ready to release a new version within the next month.
* We decided to make the next release as soon as possible, and that it should be a major release, with version number 0.3.0.0.
=== Issues on Github ===
==== Milestones ====
* Milestones are too restrictive, and one not completed could hold up a release unduly.
* We will consider the 'confirmed' label on a Github bug as making it a priority.
* We will also use the 'confirmed' label to indicate high priority for feature request and other non-bug issues which have been discussed and approved in Loomio.
==== Cleaning up old issues ====
* We're doing quite well at this at the moment.
* We will:
** encourage users on pods running the develop branch to try to reproduce bugs;
** ask for more help with this task from the DHQ account;
** encourage more users to sign up to Code Triage.
=== Improve podmin's life ===
* The points on the agenda would all be useful, but there's not much we can do during this meeting to move this forward.
=== Spam accounts ===
* The captcha and soon-coming post reporter features should help combat this.
* We should also aim to provide an easier way for podmins to delete spam accounts.
=== Press stuff ===
* We decided to give the company two weeks to provide running demo server of Diaspora*.
* If they fail we'll give them one week to remove the branding.
* Upon failure to remove the branding, escalate the issue to FSSN.
* jaywink and marekjm will write to the company to ask them to provide a demo pod within two weeks, and then as them to remove branding if this isn't done.


== IRC logs ==
== IRC logs ==
<pre>
goob: Let's start now. Hopefully Fabian will arrive soon.
flaburgan: Okay so first topic on https://wiki.diasporafoundation.org/Meetings/20140114
flaburgan: the release process
flaburgan: The point is, the stable version is too late behind the develop branch
jaywink: Wiki: https://wiki.diasporafoundation.org/Release_process
goob: I'm not sure set dates are a good idea for the project as it is now
flaburgan: many bugs fixed in september are still not available in master, this is bad
goob: while the development is being done by a fluctuating number of people doing it in their spare time.while the development is being done by a fluctuating number of people doing it in their spare time.
goob: (oops)
flaburgan: goob, fixed dates are maybe not the solution, but at least an idea
MrZYX: git log --oneline master..develop | wc -l
MrZYX: 252
flaburgan: like "max 3 months between two releases"
MrZYX: not that much
flaburgan: MrZYX, it's not about the number of changes
MrZYX: IMO it is
flaburgan: more about the time they wait
jaywink: I don't like fixed dates either, but a bit more often than currently would be nice. better release often than be too slow
goob: I like the idea of a release cycle based on achieving milestones
jaywink: we don't want too many pods moving to the develop branch so releasing working stuff regularly would be important
flaburgan: we chose a long release number, release.major.minor.hotfixes
flaburgan: so we can release minor version without problem
goob: jaywink Do you think we should do more minor releases?
jaywink: goob, yeah
jaywink: milestones are nice but what happens when some big item does not get ready that is in the next milestone? it delays everything - not good
goob: I think use milestones to prioritise rather than have them set in stone
marekjm: new version every N months regardless of the number of changes
marekjm: ?
MrZYX: also might create the false impression that work on a specific item is not desired
goob: So no release would be held up indefinitely because of one milestone not completed.
marekjm: I think milestones shouldn't be tied to minor versions IMO
flaburgan: I like the approach of mozilla, release at "fixed" date (can variate one week but not more) including only what's ready when the date is here
goob: (Milestones actually next item on flaburgan's agenda)
marekjm: flaburgan: +1
jaywink: MrZYX, you are the only one here who has done releases? how long does it take to push one out and is there any way to streamline it?
goob: prob with fixed dates is releases with little value
goob: especially for a project with no full-time developers.
jaywink: fixed date is ok if it's a fixed date that happens often :D
MrZYX: we're not enough active developers for fixed date release. period.
MrZYX: jaywink: fabian has done one or two too, florian one I think
flaburgan: that's true when we look at the october month
flaburgan: not a single commit :(
MrZYX: if the prep work is done (announcement, gem updates in the  changelog) its < 20 minutes
goob: we could perhaps set an aim something like 'At least 3 major releases per year'
flaburgan: goob, that would put some pressure
goob: also have to consider whether it's worth each podmin updating - release needs worthwhile things in it.
jaywink: what about taking an AP at every single meeting here (now that we have these, yay) to decide on release status - a simple question = release or not? then we either release or not on a monthly basis, likely less
goob: Fla, we've done 4 per year so far.
DeadSuperHero: I kind of like that.
flaburgan: my point is, I really want to avoid the situation we are right now: there was enough to release in the middle of december, and we are still waiting for it
MrZYX: jaywink +1
flaburgan: goob, major? only 2
flaburgan: jaywink, what's an AP?
jaywink: we cannot decide how many major releases we do - it depends if we have major stuff :)
goob: oh yes sorry. Got mixed up.
jaywink: flaburgan, Action Point - agenda item :D
svbergerem: jaywink +1
flaburgan: okay, this seems okay with me
flaburgan: once per month, we discuss if we want to release now or not
marekjm: jaywink: I think it's a good idea
flaburgan: is everybody okay with that?
flaburgan: one month seems nice
goob: Like jay's idea, to take poll of whether we're close to a release at each meeting.
MrZYX: we should decide who's in charge to do one too then
jaywink: must use these meetings for something ;)
MrZYX: because I got exams for the next three weeks
MrZYX: what I want to say, I'm not always here to save your back
jaywink: MrZYX, would gladly help but no rights ;)
goob: Good point. We do need more people who can do the crucial things
MrZYX: jaywink: you want some?
goob: so we're not reliant on one or two people to be available all the time.
jaywink: MrZYX, always :D
jaywink: I'm no ruby expert but I know enough git I think
DeadSuperHero: What does everyone think about task delegation?
jaywink: DeadSuperHero, what do you mean?
DeadSuperHero: I don't want to be the one to say "oh, let's use yet another tool", but something like Trello might be nice just for claiming tasks to do.
DeadSuperHero: I just wonder whether the way we delegate who's working on what is a little cluttered.
svbergerem: I think it depends on how often we need something like that
flaburgan: github is enough imo
jaywink: I guess the problem is that we don't have full time or even part time developers, only people working on their free time - so traditional task management might not work
goob: Shall we try to make a decision about release cycle?
flaburgan: goob, what do you mean?
flaburgan: for this one?
jaywink: the question: during each monthly meeting we decide whether to release or not?
marekjm: I agree with jaywink, this wouldn't probably work out well for us
svbergerem: +1
jaywink: goob, ?
flaburgan: we can discuss about the next release right now
flaburgan: we are waiting for someone to review the upgrade to devise 3.2 by MrZYX
goob: I mean what to do about the agenda item: release cycle.
goob: Is jaywink's idea the answer to that, or is there more to decide on?
flaburgan: when this will be merged in develop, develop pods will pull that and test it for at least a week
flaburgan: then, we will push a release
jaywink: goob, if my idea gained support (I think it did) then release cycle would be "per month or less" :)
flaburgan: https://github.com/diaspora/diaspora/pull/4511
flaburgan: jaywink, I would say per month or more, if we decide to report to the next meeting the release
flaburgan: that's what I understood
jaywink: well 12 meetings in a year = max 12 releases a year
svbergerem: jaywink: I'd like to add "try at least every third month" to push bug fixes to the pods but still decided on a monthly basis
goob: Do we need to do anything else to prompt getting ready towards each release?
jaywink: svbergerem, yeah agree
flaburgan: jaywink, yeah, sorry, I understood "one release per month or less (than a month) :p"
goob: Such as focus energies on particular tasks to get them in the release.
goob: Which sort of ties in with milestones (next agenda item).
jaywink: should we first decide two things;
jaywink: 1) do we agree to the proposal of deciding each release in the monthly meeting?
flaburgan: yeah, milestone powa
flaburgan: 1) yes :p
goob: I think 1) has been agreed.
jaywink: 2) do we decide to do a release asap or wait till next meeting?
flaburgan: jaywink, I think we will decide that at each meeting
jaywink: if the devise PR is wanted in, we should decide in the next
goob: on 2) do you mean for this next release, or for future meetings/releases?
jaywink: goob, this next release
marekjm: 1) decided and put in the pad
marekjm: 2) I think we should wait until the mext meeting
marekjm: *next
flaburgan: jaywink, don't you agree with what I said? we release as soon as devise is merged and tested
goob: next release asap unless there is anything major holding it up.
goob: and if someone (maybe jaywink) is available to push the release while MrZYX is busy.
flaburgan: goob, we need someone to review MrZYX work
jaywink: IMHO release asap after devise is in is fine if we agree on that
flaburgan: I agree :)
svbergerem: agree
goob: I agree
MrZYX: I abstain
goob: of course, 'asap' might mean after the next meeting if the review of the devise work takes a long time!
goob: but the intention is as soon as we can.
flaburgan: yeah
flaburgan: let's decide the release number in the same time
flaburgan: 0.2.1.0 or 0.3.0.0?
flaburgan: is this a major or a minor version?
goob: the question is: is there anything committed which merits a major version number?
flaburgan: Ruby2
flaburgan: eventually
MrZYX: captcha is a major UI/UX change -> major version bump
jaywink: +1 for major
jaywink: we've got a huge list of changes :)
goob: raven24's work on federation was talked about as the thing to make the next release a major one
goob: I'm not aware of anything else which does so in its absence.
jaywink: firefox is soon going over 30'th major release - let's not be too scared of "going too fast" :) fedgem would surely be a major too
goob: ok then (i'm easily persuaded) :)
flaburgan: goob, nothing unfortunately
marekjm: I wouldn't naming the release major in the 'release.major.minor.hotfix' scheme
marekjm: *wouldn't fear
goob: four votes for major (0.3.0.0) - anyone else want to vote?
marekjm: because it's not a first number - so it doesn't give the impression of "majorness"
svbergerem: marekjm +1
jaywink: marekjm, yeah 99% of people will still think of it as minor
jaywink: imagine firefox 0.3
svbergerem: from a users point of view I wouldn't call this major but 0.3.0.0 sounds good
flaburgan: https://github.com/diaspora/diaspora/pull/4673 is a new mobile version menu
flaburgan: this would be enough for a 0.3 too
marekjm: so it's safe to assume that we agree that there should be a jump to 0.3.x line
flaburgan: yep
goob: yes to 0.3.0.0.
svbergerem: yes
flaburgan: okay, voted
jaywink: so next: Issues on github  -> Milestones  (..sorry for rushing :D)
flaburgan: which brings us to the next topic
flaburgan: yeah, we need that :
flaburgan: :p
flaburgan: so my point is
goob: Milestones, good idea to use these more, and set them in advance as things to aim for
flaburgan: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target".
goob: and as a means of prioritising development tasks.
goob: I recommend having a separate meeting after each release in which milestones for the next release can be chosen.
jaywink: does anyone who does development work in a priority order or just what fancies them at the moment?
goob: Or I suggest that, rather than recommend.
MrZYX: so all of you have the impression that our work is just unfocused? that suddenly more will happen if you just say what needs to happen next?
goob: MrZYX not that, but I think if the priorities are made more public (using Github milestones) more people will be aware of them
goob: and can also perhaps prioritise some of the work they do.
marekjm: MrZYX: is it irony? because I think it's justified.
marekjm: the irony, I mean.
MrZYX: I don't think that awareness will increase amount of work done either
marekjm: +1
flaburgan: not by us, but maybe by new people
flaburgan: bugmashs are nice
MrZYX: bugmashs are sufficient
MrZYX: we don't run out of them
flaburgan: if we can point directly to "next"
flaburgan: milestone
flaburgan: I'm often lost in all the issue we have
MrZYX: I don't think adding milestones will improve that
jaywink: what about tags instead of milestones?
MrZYX: what tags?
jaywink: a bugmash is not a milestone. a milestone is a plan for a certain release
flaburgan: MrZYX, I think jaywink means labels
goob: I would hope that it might encourage at least some people to help MrZYX and other core developers with the key priorities
jaywink: so not really agreeing we should use milestones for this
jaywink: yeah labels
MrZYX: flaburgan: sure, I mean what specific tags are missing
goob: MrZYX, what do you suggest? Or are you happy with the situation as it is now?
jaywink: good question :D
flaburgan: MrZYX, well, we already discussed about that, maybe "high, medium and low" priorities
flaburgan: my point is, some of the issues don't affect a lot of users
goob: Perhaps a 'high priority' or 'key task' label?
MrZYX: so if we already discussed that and it didn't happen...
flaburgan: some of them are just suggestion
flaburgan: and we're lost in all these issues
goob: And if someone takes up one of them we'll try to help them as much as possible.
MrZYX: point me to a single suggestion labled with "bug" instead of "feature"
flaburgan: look at those issues https://wiki.diasporafoundation.org/Meetings/20140114#Milestones
flaburgan: they have to be fixed asap
goob: (obviously depends on having enough people available to help!)
flaburgan: but I forgot them for this release
MrZYX: I think that is the major misconception here, adding more project management techniques won't suddenly attract new people
flaburgan: I agree
jaywink: MrZYX, agree - we need more devs not management :)
MrZYX: or make the involved people have more time
flaburgan: I just think that, goob tried to keep track of dozens of issues on loomio to know what he can present on diaspora hq
flaburgan: this should be done directly on github
goob: I'm thinking to try to encourage people who do a bit of development here and there to tackle the issues which really need work
flaburgan: a milestone is a way to say "this is the target"
svbergerem: IMO we should go through some bugs before every meeting, discuss what needs to be done ASAP and put those in a diasporahq post
goob: If a milestone says 'We want this done before the next release' it might encourage someone to take it on first.
flaburgan: svbergerem, agree
flaburgan: goob, I don't find where you listed all those issues
flaburgan: it was on diaspora or on loomio?
goob: I'd prefer not to get into discussion of individual bugs/issues in the meetings.
svbergerem: goob: a milestone sounds like "this will be done until the next release" which is just wrong
MrZYX: +1
MrZYX: additionally it sounds like "everything else won't be done" which is also wrong
flaburgan: agree
flaburgan: so we will not use milestone for that
flaburgan: but don't you agree we should have an easy way to access to the issues which have to be fixed asap?
jaywink: flaburgan, I think the only way would be to get someone to assign labels to them on github
MrZYX: what about using the confirmed label?
goob: So how best to make the prioritisation of tasks more public? Or are things best left as they are?
flaburgan: the confirmed just means "I can reproduce"
jaywink: something like "priority" would be more describing imho
flaburgan: yeah I'm more in favour of something like that
MrZYX: thing is, prioritizing a bug I can't reproduce won't make it fixed faster...
flaburgan: MrZYX, that's a different point
jaywink: well labels should not be abused, I think no one would mark issues priority unless they are confirmed :) have we been using the confirmed label before? only 8 issues are confirmed if so
goob: If a bug can't be reproduced, it's unlikely to be a high priority!
MrZYX: okay, I won't do the added maintenance work of deciding what to label as priority, if you find somebody to do it, fine with me, I can ignore that just fine
flaburgan: I just want to be able to quickly sort issues that are affecting a really small number of users, issues that are an interesting suggestion but not urgent, and the issues like the 404 with opengraph which affect every users on almost every posts they do
jaywink: do agree with flaburgan that there is no good way to find "urgent" issues from the labels
flaburgan: maybe it's not that important
flaburgan: I agree to do the "priority" labeling
flaburgan: even every labelling btw
svbergerem: "confirmed" sounds good to me
flaburgan: unfortunately I need the merge rights to do that
flaburgan: okay let's vote
svbergerem: you know that those are bugs you can reproduce and we really want that someone fixes those
jaywink: svbergerem, if we agree confirmed then cool
flaburgan: we can use confirmed for that if we want, even if that's not the initial purpose
flaburgan: okay let's vote
flaburgan: do we agree to use a label to mark issues which should be solved in priority?
goob: We can also publicise priority tasks via DHQ
jaywink: not sure about "should be solved" part but agree to using a label ;) confirmed is fine
jaywink: so +1 I guess
svbergerem: "confirmed" is no priority IMHO. It just tells you that it definitely needs to be done
marekjm: svbergerem: "it definitely needs to be done" which is priority ;-)
goob: 'confirmed' is fine for bugs, but what about things that are not bugs?
jaywink: vote vote vote - we can tune things later ;)
goob: e.g. federation code, account migration, etc - which are priorities.
goob: how to we make it clear to anyone who wants to join in that these are priorities above many other things?
MrZYX: you don't join just to join
jaywink: goob, well a feature would be confirmed at least if it has been decided upon - eg for example a vote on loomio or if it is clear it is needed by everyone and how to do it
MrZYX: you join with your own purpose
jaywink: like the bootstrap thingy
MrZYX: once again, it's not about coordinating workforce, our issue is lack of workforce
jaywink: people should above all work on what they want - not what we tell them to
goob: the purpose might be liking the project and wanting to help improve it.
jaywink: it's the important thing in open source
flaburgan: okay so maybe we should have different approach
flaburgan: we could use https://wiki.diasporafoundation.org/TODO-list to track the issues we'd like to solve in priority
flaburgan: and link to this page with the diaspora HQ account
flaburgan: what do you think?
flaburgan: but that means maintain this page up to date
jaywink: if github had better access management I would definitely vote github :)
mode (+v goob) by MrZYX
goob: (oops) - definitely, that's something i'd like to try to address separately. good to both try to encourage people to join in, and to have a list of tasks we really want people to work on.
goob: or am I barking up the wrong tree?
jaywink: the problem with syncing issues to different places is they go out of sync
flaburgan: jaywink, agree
jaywink: so the confirmed label sounds the best solution imho, though it requires the github team to maybe rethink some access rights - I think only a minor part of the currrent members actually use diaspora ;)
MrZYX: I've seen projects doing separate repositories for issue tracking
flaburgan: that's why I'm more in favour of github
jaywink: MrZYX, well I meant in general that one tool for issues, etc .. now it is github
MrZYX: (not sure I like that approach too much though)
svbergerem: "confirmed" label for reproducable bugs and features that were decided on loomio?
jaywink: +1 for that
marekjm: yup, I think this is the way to go
flaburgan: I'm still not convinced "confirmed" is the best word to use
flaburgan: but I agree to do the label task
goob: If everyone agrees that 'confirmed' = 'priority', it should be fine.
goob: So I'll agree to that.
goob: (Just realised we've been at this longer than an hour and we're only on item 2…)
jaywink: yeah we should move on
goob: OK, agree that issues with the confirmed label should be treated as priority?
flaburgan: fine with e
flaburgan: me
goob: Fla and I can also start to ask for help with some of the non-bug priorities via DHQ.
flaburgan: yep
flaburgan: but nothing controversial here so no need to debate :p
goob: Yep, debate on Loomio for anything major or controversial before 'confirmed' is set.
goob: Everyone happy to move on to the next item?
flaburgan: so next topic
svbergerem: yep
jaywink: plz :)
flaburgan: svbergerem, clean up issues
svbergerem: Clean up issues: just do it :-P
goob: I think we're cleaning up old issues at a reasonable rate at the moment.
goob: but can certainly publicise this task more to get more people involved
flaburgan: I just did a post about that with my podmin account on diaspora-fr.org
flaburgan: my pod is running the develop branch
flaburgan: so the users can help to try to reproduce issues
goob: as long as that won't lead to lots of people finding old issues of 'I want feature x!' and bumping them all. ;)
flaburgan: :p
jaywink: yeah - one thing to do via dhq account imho would be to get people to sign up to CodeTriage
goob: So things OK as they are, we'll try to publicise this task a bit more?
goob: jaywink, yes good idea.
goob: So we're still using Code Triage, then? I had a feeling it had dropped out of use.
jaywink: http://www.codetriage.com/diaspora/diaspora
jaywink: 46 subscribers - we can get more
goob: Is it still wanted as a tool? @MrZYX?
jaywink: goob, it's not a tool for the project - anyone can use it without the project agreing :)
MrZYX: ^
goob: OK. If it's useful to publicise Code Triage via DHQ I'm happy to do that.
jaywink: it's just basically "mail me a daily issue from this project plz"
jaywink: goob, that would be cool :)
goob: Is there anything else about cleaning up issues we need to discuss? Or can we move on?
flaburgan: okay, so goob and me are going to promote codetriage and say to users that me need people to try to reproduce bug
svbergerem: we should also work on the feature requests: put some of those on loomio and vote
jaywink: yeah definitely close or at least vote+close on some of the weirder ones.. ;)
svbergerem: yep
flaburgan: agree
mode (+v goob) by MrZYX
goob: Sorry MrZYX connection keeps dropping out.
MrZYX: no worries, that's a script ;)
goob: Oh good.
goob: Re Loomio: use it if there's a debate about whether a feature would be desirable.
goob: Not everything needs a vote.
flaburgan: let's go directly to the hot topic of the week, cause it's already late
flaburgan: Press stuff
flaburgan: (it's not a good title)
flaburgan: https://wiki.diasporafoundation.org/Meetings/20140114#Press_stuff
MrZYX: I'd say lets ask him for a demo account with a running pod
MrZYX: set a deadline of two weeks
jaywink: MrZYX, good idea
MrZYX: after that ask to remove our branding
MrZYX: set a deadline of another week
MrZYX: and if then still needed escalate to the FSSN
jaywink: Awesome plan :)
MrZYX: I don't think he'll succeed in providing that demo account
goob: Sounds good. Can we insist on removal of branding? I.e is the name and logo trademarked? I forgot what happened with that.
MrZYX: so we don't need to worry about his request
MrZYX: goob: yes it is and my latest status is that the FSSN owns it now
flaburgan: seems okay
goob: OK thanks. It certainly sounds like a good plan. I'm happy with it.
flaburgan: who is writing to him?
svbergerem: Just in case he can provide a demo account: decide in the next meeting what to do?
jaywink: I wouldn't request removal of branding IF he can provide the demo account
jaywink: ye
jaywink: svbergerem, +1
MrZYX: svbergerem: I'd say so
MrZYX: jaywink: sure
goob: We can ask for a prominent notice on that page saying 'Arvixe is in no way connected with or endorsed by Diaspora' or wording to that effect.
MrZYX: I think people get that
goob: But to start with, proceed with MrZYX's suggested plan.
MrZYX: look at the wordpress hosters
goob: Anyone want to volunteer to write to them? I'm happy to collaborate with wording.
MrZYX: it's clear that they just run the software for you
jaywink: so who will write? if no one else wants to take this task, I can
goob: OK MrZYX, thanks.
flaburgan: so goob or jaywink?
marekjm: I can collaborate with @jaywink on the writing task (sounds like some school homework...)
flaburgan: ^^
goob: If jaywink and marekjm are happy to work together, that sounds good to me. OK with you two?
marekjm: fine with me. jaywink?
flaburgan: you can post the message on loomio first
flaburgan: we should probably open a loomio topic about the whole story anyway
jaywink: do we really need to discuss an email sent out? :)
goob: I think no need. We've agreed on what the message should contain. I'm happy to leave fine wording up to them.
flaburgan: it's just to keep track
jaywink: it doesnt' have to be long, just saying that they should be able to provide a running diaspora installation as a demo to us and confirm the minimum specs listed on the page to match that - if not, false promises should be removed?
flaburgan: so, next topic, spammer accounts (it will bring us to the admin task)
flaburgan: do we need something else than captcha?
marekjm: jaywink: exactly that.
goob: jaywink, I think first email can simply request demo pod, and then email to request removal of branding if demo pod not up within two weeks.
goob: (I mean, email again after two weeks).
svbergerem: agree, next topic?
goob: Spammers: there's also the post reporter feature – https://github.com/diaspora/diaspora/pull/4517 – should also help
svbergerem: goob: I agree
goob: Won't stop them signing up, but may get them removed more quickly.
jaywink: need to go guys - thanks for the meeting :) will catch up with logs tomorrow. see ya!
goob: Thanks jaywink. Sleep well, mate.
marekjm: bye jaywink. I'll PM you about the email to that company.
svbergerem: I think captcha and post reporter feature should be fine
flaburgan: we need to provide an easy way for podmins to delete users
svbergerem: thats right
flaburgan: report users is kind of useless with that
flaburgan: without that sorry
flaburgan: so this is the next topic
flaburgan: and last one for today
flaburgan: we need to simply podmins life
flaburgan: the current admin panel is kind of useless
flaburgan: https://wiki.diasporafoundation.org/Meetings/20140114#A_nice_admin_panel
goob: I can agree to 'simplify podmins' lives' and 'improve admin panel'
goob: but what can we usefully decide on here and now?
flaburgan: that this is the priority for the next release?
flaburgan: :p
svbergerem: add feature requests on github?
MrZYX: do you know the facepalm smiley? here it is for you: m( I won't repeat myself another time
flaburgan: https://github.com/diaspora/diaspora/issues/4183
flaburgan: don't get it sorry
MrZYX: things don't happen by saying they're needed
flaburgan: yeah I know
flaburgan: but that's not in my skills at the moment
MrZYX: but that's not relevant
svbergerem: what about the feature requests to keep track of that?
goob: Fla, touché!
marekjm: OK guys, I gotta go. If someone wants to keep pad updated - feel free to. I tried to protocol most of the decisions made so far on the meeting.
svbergerem: (4183 seems to be just about the "clean ghost pods & users)
MrZYX: I think we can wrap up, no?
goob: We can all agree that it's important to improve the podmin experience, but I can't see what we can decide on other than that.
flaburgan: svbergerem, yeah, I'll open a new issue
flaburgan: goob, nothing
flaburgan: I just wanted to point that the focus should be on that for the next release
svbergerem: MrZYX: +1
goob: flaburgan, let's make one of the DHQ posts a request for help on these tasks.
flaburgan: goob, okay
goob: I'm happy to wrap up. Just been writing some minutes which I'll put on the wiki.
flaburgan: everything is already summarized here https://flaburgan.framapad.org/4
</pre>
== Other meetings ==
* See [[Meetings]] for an overview.
{{Special:Prefixindex/Meetings/}}
[[Category:Community]]
[[Category:Meetings]]

Latest revision as of 03:20, 17 August 2017

Topic to discuss

Release process

Thoughts on the release process? Do we want to schedule releases? How often do we want to release?

Issues on github

Milestones

Fla: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target".

So, what do we want to see in the next release (not the one coming right now, the next one)?

Clean up issues

  • Read some old issues, starting with the least recently updated ones.
  • Check if the bug still exists, if some more information is needed and if the issue is suitable for newcomers.
  • If it is an important or easy to fix issue: decide if we want to add it to a milestone / promote it in a bugmash monday

These tasks can be done by a non-technical person, so we can call for contributors, we only need people on pods using the develop branch.

Improve podmin's life

A nice admin panel

It's important to help podmins to deal with common tasks easily without having to use command lines / geeky stuff. The admin panel should be improved to add new actions like:

  • Ability to remove a user (including remote user) to fight spam
  • Ability to close / reopen a local user
  • Ability to clean ghost pods to improve performance
  • The list of the 500 errors occurred
  • Current memory / cpu used?

Related github issue: https://github.com/diaspora/diaspora/issues/4183

Graphical interface to install / update

Spammer accounts

Recently more spam has been appearing on Diaspora pods. Some things are already being fixed like Captcha support which should land soon in develop. Other things we should do to combat spam?

Press stuff

A hosting company recently sent this to the press team, promising "diaspora hosting for as low as $4/mo" in a shared hosting environment. They are basically making (afaict) non-valid promises using the Diaspora official branding (see included url). 

    Hello Sean,

I noticed that you are the community manager so I wanted to reach out directly. Please let me know if there is someone else I should contact to discuss further.

My name is Gregg Hawkins and I'm the marketing manager for Arvixe, a web hosting company. I wanted to inquire about becoming a recommended hosting provider to the visitors of your website. I have created a landing page, which can be found here: http://www.arvixe.com/diaspora-hosting

More specifically, I'm wondering what it would take for you to create a tab on your website that says "Web Hosting" and on that page simply put a paragraph introducing Arvixe and then linking to us?

I'll be looking forward to a positive response!

Regards,

Gregg Hawkins
Marketing Operations Officer

How shall we respond?

What did we decide?

Release process

  • We won't commit to a release cycle with a new release within a set time period.
  • We'll decide at each monthly meeting whether we are ready to release a new version within the next month.
  • We decided to make the next release as soon as possible, and that it should be a major release, with version number 0.3.0.0.

Issues on Github

Milestones

  • Milestones are too restrictive, and one not completed could hold up a release unduly.
  • We will consider the 'confirmed' label on a Github bug as making it a priority.
  • We will also use the 'confirmed' label to indicate high priority for feature request and other non-bug issues which have been discussed and approved in Loomio.

Cleaning up old issues

  • We're doing quite well at this at the moment.
  • We will:
    • encourage users on pods running the develop branch to try to reproduce bugs;
    • ask for more help with this task from the DHQ account;
    • encourage more users to sign up to Code Triage.

Improve podmin's life

  • The points on the agenda would all be useful, but there's not much we can do during this meeting to move this forward.

Spam accounts

  • The captcha and soon-coming post reporter features should help combat this.
  • We should also aim to provide an easier way for podmins to delete spam accounts.

Press stuff

  • We decided to give the company two weeks to provide running demo server of Diaspora*.
  • If they fail we'll give them one week to remove the branding.
  • Upon failure to remove the branding, escalate the issue to FSSN.
  • jaywink and marekjm will write to the company to ask them to provide a demo pod within two weeks, and then as them to remove branding if this isn't done.


IRC logs

goob: Let's start now. Hopefully Fabian will arrive soon.
flaburgan: Okay so first topic on https://wiki.diasporafoundation.org/Meetings/20140114
flaburgan: the release process
flaburgan: The point is, the stable version is too late behind the develop branch
jaywink: Wiki: https://wiki.diasporafoundation.org/Release_process
goob: I'm not sure set dates are a good idea for the project as it is now
flaburgan: many bugs fixed in september are still not available in master, this is bad
goob: while the development is being done by a fluctuating number of people doing it in their spare time.while the development is being done by a fluctuating number of people doing it in their spare time.
goob: (oops)
flaburgan: goob, fixed dates are maybe not the solution, but at least an idea
MrZYX: git log --oneline master..develop | wc -l
MrZYX: 252
flaburgan: like "max 3 months between two releases"
MrZYX: not that much
flaburgan: MrZYX, it's not about the number of changes
MrZYX: IMO it is
flaburgan: more about the time they wait
jaywink: I don't like fixed dates either, but a bit more often than currently would be nice. better release often than be too slow
goob: I like the idea of a release cycle based on achieving milestones
jaywink: we don't want too many pods moving to the develop branch so releasing working stuff regularly would be important
flaburgan: we chose a long release number, release.major.minor.hotfixes
flaburgan: so we can release minor version without problem
goob: jaywink Do you think we should do more minor releases?
jaywink: goob, yeah
jaywink: milestones are nice but what happens when some big item does not get ready that is in the next milestone? it delays everything - not good
goob: I think use milestones to prioritise rather than have them set in stone
marekjm: new version every N months regardless of the number of changes
marekjm: ?
MrZYX: also might create the false impression that work on a specific item is not desired
goob: So no release would be held up indefinitely because of one milestone not completed.
marekjm: I think milestones shouldn't be tied to minor versions IMO
flaburgan: I like the approach of mozilla, release at "fixed" date (can variate one week but not more) including only what's ready when the date is here
goob: (Milestones actually next item on flaburgan's agenda)
marekjm: flaburgan: +1
jaywink: MrZYX, you are the only one here who has done releases? how long does it take to push one out and is there any way to streamline it?
goob: prob with fixed dates is releases with little value
goob: especially for a project with no full-time developers.
jaywink: fixed date is ok if it's a fixed date that happens often :D
MrZYX: we're not enough active developers for fixed date release. period.
MrZYX: jaywink: fabian has done one or two too, florian one I think
flaburgan: that's true when we look at the october month
flaburgan: not a single commit :(
MrZYX: if the prep work is done (announcement, gem updates in the  changelog) its < 20 minutes
goob: we could perhaps set an aim something like 'At least 3 major releases per year'
flaburgan: goob, that would put some pressure
goob: also have to consider whether it's worth each podmin updating - release needs worthwhile things in it.
jaywink: what about taking an AP at every single meeting here (now that we have these, yay) to decide on release status - a simple question = release or not? then we either release or not on a monthly basis, likely less
goob: Fla, we've done 4 per year so far.
DeadSuperHero: I kind of like that.
flaburgan: my point is, I really want to avoid the situation we are right now: there was enough to release in the middle of december, and we are still waiting for it
MrZYX: jaywink +1
flaburgan: goob, major? only 2
flaburgan: jaywink, what's an AP?
jaywink: we cannot decide how many major releases we do - it depends if we have major stuff :)
goob: oh yes sorry. Got mixed up.
jaywink: flaburgan, Action Point - agenda item :D
svbergerem: jaywink +1
flaburgan: okay, this seems okay with me
flaburgan: once per month, we discuss if we want to release now or not
marekjm: jaywink: I think it's a good idea
flaburgan: is everybody okay with that?
flaburgan: one month seems nice
goob: Like jay's idea, to take poll of whether we're close to a release at each meeting.
MrZYX: we should decide who's in charge to do one too then
jaywink: must use these meetings for something ;)
MrZYX: because I got exams for the next three weeks
MrZYX: what I want to say, I'm not always here to save your back
jaywink: MrZYX, would gladly help but no rights ;)
goob: Good point. We do need more people who can do the crucial things
MrZYX: jaywink: you want some?
goob: so we're not reliant on one or two people to be available all the time.
jaywink: MrZYX, always :D
jaywink: I'm no ruby expert but I know enough git I think
DeadSuperHero: What does everyone think about task delegation?
jaywink: DeadSuperHero, what do you mean?
DeadSuperHero: I don't want to be the one to say "oh, let's use yet another tool", but something like Trello might be nice just for claiming tasks to do.
DeadSuperHero: I just wonder whether the way we delegate who's working on what is a little cluttered.
svbergerem: I think it depends on how often we need something like that
flaburgan: github is enough imo
jaywink: I guess the problem is that we don't have full time or even part time developers, only people working on their free time - so traditional task management might not work
goob: Shall we try to make a decision about release cycle?
flaburgan: goob, what do you mean?
flaburgan: for this one?
jaywink: the question: during each monthly meeting we decide whether to release or not?
marekjm: I agree with jaywink, this wouldn't probably work out well for us
svbergerem: +1
jaywink: goob, ?
flaburgan: we can discuss about the next release right now
flaburgan: we are waiting for someone to review the upgrade to devise 3.2 by MrZYX
goob: I mean what to do about the agenda item: release cycle.
goob: Is jaywink's idea the answer to that, or is there more to decide on?
flaburgan: when this will be merged in develop, develop pods will pull that and test it for at least a week
flaburgan: then, we will push a release
jaywink: goob, if my idea gained support (I think it did) then release cycle would be "per month or less" :)
flaburgan: https://github.com/diaspora/diaspora/pull/4511
flaburgan: jaywink, I would say per month or more, if we decide to report to the next meeting the release
flaburgan: that's what I understood
jaywink: well 12 meetings in a year = max 12 releases a year
svbergerem: jaywink: I'd like to add "try at least every third month" to push bug fixes to the pods but still decided on a monthly basis
goob: Do we need to do anything else to prompt getting ready towards each release?
jaywink: svbergerem, yeah agree
flaburgan: jaywink, yeah, sorry, I understood "one release per month or less (than a month) :p"
goob: Such as focus energies on particular tasks to get them in the release.
goob: Which sort of ties in with milestones (next agenda item).
jaywink: should we first decide two things;
jaywink: 1) do we agree to the proposal of deciding each release in the monthly meeting?
flaburgan: yeah, milestone powa
flaburgan: 1) yes :p
goob: I think 1) has been agreed.
jaywink: 2) do we decide to do a release asap or wait till next meeting?
flaburgan: jaywink, I think we will decide that at each meeting
jaywink: if the devise PR is wanted in, we should decide in the next
goob: on 2) do you mean for this next release, or for future meetings/releases?
jaywink: goob, this next release
marekjm: 1) decided and put in the pad
marekjm: 2) I think we should wait until the mext meeting
marekjm: *next
flaburgan: jaywink, don't you agree with what I said? we release as soon as devise is merged and tested
goob: next release asap unless there is anything major holding it up.
goob: and if someone (maybe jaywink) is available to push the release while MrZYX is busy.
flaburgan: goob, we need someone to review MrZYX work
jaywink: IMHO release asap after devise is in is fine if we agree on that
flaburgan: I agree :)
svbergerem: agree
goob: I agree
MrZYX: I abstain
goob: of course, 'asap' might mean after the next meeting if the review of the devise work takes a long time!
goob: but the intention is as soon as we can.
flaburgan: yeah
flaburgan: let's decide the release number in the same time
flaburgan: 0.2.1.0 or 0.3.0.0?
flaburgan: is this a major or a minor version?
goob: the question is: is there anything committed which merits a major version number?
flaburgan: Ruby2
flaburgan: eventually
MrZYX: captcha is a major UI/UX change -> major version bump
jaywink: +1 for major
jaywink: we've got a huge list of changes :)
goob: raven24's work on federation was talked about as the thing to make the next release a major one
goob: I'm not aware of anything else which does so in its absence.
jaywink: firefox is soon going over 30'th major release - let's not be too scared of "going too fast" :) fedgem would surely be a major too
goob: ok then (i'm easily persuaded) :)
flaburgan: goob, nothing unfortunately
marekjm: I wouldn't naming the release major in the 'release.major.minor.hotfix' scheme
marekjm: *wouldn't fear
goob: four votes for major (0.3.0.0) - anyone else want to vote?
marekjm: because it's not a first number - so it doesn't give the impression of "majorness"
svbergerem: marekjm +1
jaywink: marekjm, yeah 99% of people will still think of it as minor
jaywink: imagine firefox 0.3
svbergerem: from a users point of view I wouldn't call this major but 0.3.0.0 sounds good
flaburgan: https://github.com/diaspora/diaspora/pull/4673 is a new mobile version menu
flaburgan: this would be enough for a 0.3 too
marekjm: so it's safe to assume that we agree that there should be a jump to 0.3.x line
flaburgan: yep
goob: yes to 0.3.0.0.
svbergerem: yes
flaburgan: okay, voted
jaywink: so next: Issues on github  -> Milestones  (..sorry for rushing :D)
flaburgan: which brings us to the next topic
flaburgan: yeah, we need that :
flaburgan: :p
flaburgan: so my point is
goob: Milestones, good idea to use these more, and set them in advance as things to aim for
flaburgan: I think we should use more the "milestone feature" of github. Right now, we almost only use it when something is already merged. To decide during meetings what we want to see in the next meeting and put a milestone on it would allow to share this to potential contributors saying "this is the target".
goob: and as a means of prioritising development tasks.
goob: I recommend having a separate meeting after each release in which milestones for the next release can be chosen.
jaywink: does anyone who does development work in a priority order or just what fancies them at the moment?
goob: Or I suggest that, rather than recommend.
MrZYX: so all of you have the impression that our work is just unfocused? that suddenly more will happen if you just say what needs to happen next?
goob: MrZYX not that, but I think if the priorities are made more public (using Github milestones) more people will be aware of them
goob: and can also perhaps prioritise some of the work they do.
marekjm: MrZYX: is it irony? because I think it's justified.
marekjm: the irony, I mean.
MrZYX: I don't think that awareness will increase amount of work done either
marekjm: +1
flaburgan: not by us, but maybe by new people
flaburgan: bugmashs are nice
MrZYX: bugmashs are sufficient
MrZYX: we don't run out of them
flaburgan: if we can point directly to "next"
flaburgan: milestone
flaburgan: I'm often lost in all the issue we have
MrZYX: I don't think adding milestones will improve that
jaywink: what about tags instead of milestones?
MrZYX: what tags?
jaywink: a bugmash is not a milestone. a milestone is a plan for a certain release
flaburgan: MrZYX, I think jaywink means labels
goob: I would hope that it might encourage at least some people to help MrZYX and other core developers with the key priorities
jaywink: so not really agreeing we should use milestones for this
jaywink: yeah labels
MrZYX: flaburgan: sure, I mean what specific tags are missing
goob: MrZYX, what do you suggest? Or are you happy with the situation as it is now?
jaywink: good question :D
flaburgan: MrZYX, well, we already discussed about that, maybe "high, medium and low" priorities
flaburgan: my point is, some of the issues don't affect a lot of users
goob: Perhaps a 'high priority' or 'key task' label?
MrZYX: so if we already discussed that and it didn't happen...
flaburgan: some of them are just suggestion
flaburgan: and we're lost in all these issues
goob: And if someone takes up one of them we'll try to help them as much as possible.
MrZYX: point me to a single suggestion labled with "bug" instead of "feature"
flaburgan: look at those issues https://wiki.diasporafoundation.org/Meetings/20140114#Milestones
flaburgan: they have to be fixed asap
goob: (obviously depends on having enough people available to help!)
flaburgan: but I forgot them for this release
MrZYX: I think that is the major misconception here, adding more project management techniques won't suddenly attract new people
flaburgan: I agree
jaywink: MrZYX, agree - we need more devs not management :)
MrZYX: or make the involved people have more time
flaburgan: I just think that, goob tried to keep track of dozens of issues on loomio to know what he can present on diaspora hq
flaburgan: this should be done directly on github
goob: I'm thinking to try to encourage people who do a bit of development here and there to tackle the issues which really need work
flaburgan: a milestone is a way to say "this is the target"
svbergerem: IMO we should go through some bugs before every meeting, discuss what needs to be done ASAP and put those in a diasporahq post
goob: If a milestone says 'We want this done before the next release' it might encourage someone to take it on first.
flaburgan: svbergerem, agree
flaburgan: goob, I don't find where you listed all those issues
flaburgan: it was on diaspora or on loomio?
goob: I'd prefer not to get into discussion of individual bugs/issues in the meetings.
svbergerem: goob: a milestone sounds like "this will be done until the next release" which is just wrong
MrZYX: +1
MrZYX: additionally it sounds like "everything else won't be done" which is also wrong
flaburgan: agree
flaburgan: so we will not use milestone for that
flaburgan: but don't you agree we should have an easy way to access to the issues which have to be fixed asap?
jaywink: flaburgan, I think the only way would be to get someone to assign labels to them on github
MrZYX: what about using the confirmed label?
goob: So how best to make the prioritisation of tasks more public? Or are things best left as they are?
flaburgan: the confirmed just means "I can reproduce"
jaywink: something like "priority" would be more describing imho
flaburgan: yeah I'm more in favour of something like that
MrZYX: thing is, prioritizing a bug I can't reproduce won't make it fixed faster...
flaburgan: MrZYX, that's a different point
jaywink: well labels should not be abused, I think no one would mark issues priority unless they are confirmed :) have we been using the confirmed label before? only 8 issues are confirmed if so
goob: If a bug can't be reproduced, it's unlikely to be a high priority!
MrZYX: okay, I won't do the added maintenance work of deciding what to label as priority, if you find somebody to do it, fine with me, I can ignore that just fine
flaburgan: I just want to be able to quickly sort issues that are affecting a really small number of users, issues that are an interesting suggestion but not urgent, and the issues like the 404 with opengraph which affect every users on almost every posts they do
jaywink: do agree with flaburgan that there is no good way to find "urgent" issues from the labels
flaburgan: maybe it's not that important
flaburgan: I agree to do the "priority" labeling
flaburgan: even every labelling btw
svbergerem: "confirmed" sounds good to me
flaburgan: unfortunately I need the merge rights to do that
flaburgan: okay let's vote
svbergerem: you know that those are bugs you can reproduce and we really want that someone fixes those
jaywink: svbergerem, if we agree confirmed then cool
flaburgan: we can use confirmed for that if we want, even if that's not the initial purpose
flaburgan: okay let's vote
flaburgan: do we agree to use a label to mark issues which should be solved in priority?
goob: We can also publicise priority tasks via DHQ
jaywink: not sure about "should be solved" part but agree to using a label ;) confirmed is fine
jaywink: so +1 I guess
svbergerem: "confirmed" is no priority IMHO. It just tells you that it definitely needs to be done
marekjm: svbergerem: "it definitely needs to be done" which is priority ;-)
goob: 'confirmed' is fine for bugs, but what about things that are not bugs?
jaywink: vote vote vote - we can tune things later ;)
goob: e.g. federation code, account migration, etc - which are priorities.
goob: how to we make it clear to anyone who wants to join in that these are priorities above many other things?
MrZYX: you don't join just to join
jaywink: goob, well a feature would be confirmed at least if it has been decided upon - eg for example a vote on loomio or if it is clear it is needed by everyone and how to do it
MrZYX: you join with your own purpose
jaywink: like the bootstrap thingy
MrZYX: once again, it's not about coordinating workforce, our issue is lack of workforce
jaywink: people should above all work on what they want - not what we tell them to
goob: the purpose might be liking the project and wanting to help improve it.
jaywink: it's the important thing in open source
flaburgan: okay so maybe we should have different approach
flaburgan: we could use https://wiki.diasporafoundation.org/TODO-list to track the issues we'd like to solve in priority
flaburgan: and link to this page with the diaspora HQ account
flaburgan: what do you think?
flaburgan: but that means maintain this page up to date
jaywink: if github had better access management I would definitely vote github :)
mode (+v goob) by MrZYX
goob: (oops) - definitely, that's something i'd like to try to address separately. good to both try to encourage people to join in, and to have a list of tasks we really want people to work on.
goob: or am I barking up the wrong tree?
jaywink: the problem with syncing issues to different places is they go out of sync
flaburgan: jaywink, agree
jaywink: so the confirmed label sounds the best solution imho, though it requires the github team to maybe rethink some access rights - I think only a minor part of the currrent members actually use diaspora ;)
MrZYX: I've seen projects doing separate repositories for issue tracking
flaburgan: that's why I'm more in favour of github
jaywink: MrZYX, well I meant in general that one tool for issues, etc .. now it is github
MrZYX: (not sure I like that approach too much though)
svbergerem: "confirmed" label for reproducable bugs and features that were decided on loomio?
jaywink: +1 for that
marekjm: yup, I think this is the way to go
flaburgan: I'm still not convinced "confirmed" is the best word to use
flaburgan: but I agree to do the label task
goob: If everyone agrees that 'confirmed' = 'priority', it should be fine.
goob: So I'll agree to that.
goob: (Just realised we've been at this longer than an hour and we're only on item 2…)
jaywink: yeah we should move on
goob: OK, agree that issues with the confirmed label should be treated as priority?
flaburgan: fine with e
flaburgan: me
goob: Fla and I can also start to ask for help with some of the non-bug priorities via DHQ.
flaburgan: yep
flaburgan: but nothing controversial here so no need to debate :p
goob: Yep, debate on Loomio for anything major or controversial before 'confirmed' is set.
goob: Everyone happy to move on to the next item?
flaburgan: so next topic
svbergerem: yep
jaywink: plz :)
flaburgan: svbergerem, clean up issues
svbergerem: Clean up issues: just do it :-P
goob: I think we're cleaning up old issues at a reasonable rate at the moment.
goob: but can certainly publicise this task more to get more people involved
flaburgan: I just did a post about that with my podmin account on diaspora-fr.org
flaburgan: my pod is running the develop branch
flaburgan: so the users can help to try to reproduce issues
goob: as long as that won't lead to lots of people finding old issues of 'I want feature x!' and bumping them all. ;)
flaburgan: :p
jaywink: yeah - one thing to do via dhq account imho would be to get people to sign up to CodeTriage
goob: So things OK as they are, we'll try to publicise this task a bit more?
goob: jaywink, yes good idea.
goob: So we're still using Code Triage, then? I had a feeling it had dropped out of use.
jaywink: http://www.codetriage.com/diaspora/diaspora
jaywink: 46 subscribers - we can get more
goob: Is it still wanted as a tool? @MrZYX?
jaywink: goob, it's not a tool for the project - anyone can use it without the project agreing :)
MrZYX: ^
goob: OK. If it's useful to publicise Code Triage via DHQ I'm happy to do that.
jaywink: it's just basically "mail me a daily issue from this project plz"
jaywink: goob, that would be cool :)
goob: Is there anything else about cleaning up issues we need to discuss? Or can we move on?
flaburgan: okay, so goob and me are going to promote codetriage and say to users that me need people to try to reproduce bug
svbergerem: we should also work on the feature requests: put some of those on loomio and vote
jaywink: yeah definitely close or at least vote+close on some of the weirder ones.. ;)
svbergerem: yep
flaburgan: agree
mode (+v goob) by MrZYX
goob: Sorry MrZYX connection keeps dropping out.
MrZYX: no worries, that's a script ;)
goob: Oh good.
goob: Re Loomio: use it if there's a debate about whether a feature would be desirable.
goob: Not everything needs a vote.
flaburgan: let's go directly to the hot topic of the week, cause it's already late
flaburgan: Press stuff
flaburgan: (it's not a good title)
flaburgan: https://wiki.diasporafoundation.org/Meetings/20140114#Press_stuff
MrZYX: I'd say lets ask him for a demo account with a running pod
MrZYX: set a deadline of two weeks
jaywink: MrZYX, good idea
MrZYX: after that ask to remove our branding
MrZYX: set a deadline of another week
MrZYX: and if then still needed escalate to the FSSN
jaywink: Awesome plan :)
MrZYX: I don't think he'll succeed in providing that demo account
goob: Sounds good. Can we insist on removal of branding? I.e is the name and logo trademarked? I forgot what happened with that.
MrZYX: so we don't need to worry about his request
MrZYX: goob: yes it is and my latest status is that the FSSN owns it now
flaburgan: seems okay
goob: OK thanks. It certainly sounds like a good plan. I'm happy with it.
flaburgan: who is writing to him?
svbergerem: Just in case he can provide a demo account: decide in the next meeting what to do?
jaywink: I wouldn't request removal of branding IF he can provide the demo account
jaywink: ye
jaywink: svbergerem, +1
MrZYX: svbergerem: I'd say so
MrZYX: jaywink: sure
goob: We can ask for a prominent notice on that page saying 'Arvixe is in no way connected with or endorsed by Diaspora' or wording to that effect.
MrZYX: I think people get that
goob: But to start with, proceed with MrZYX's suggested plan.
MrZYX: look at the wordpress hosters
goob: Anyone want to volunteer to write to them? I'm happy to collaborate with wording.
MrZYX: it's clear that they just run the software for you
jaywink: so who will write? if no one else wants to take this task, I can
goob: OK MrZYX, thanks.
flaburgan: so goob or jaywink?
marekjm: I can collaborate with @jaywink on the writing task (sounds like some school homework...)
flaburgan: ^^
goob: If jaywink and marekjm are happy to work together, that sounds good to me. OK with you two?
marekjm: fine with me. jaywink?
flaburgan: you can post the message on loomio first
flaburgan: we should probably open a loomio topic about the whole story anyway
jaywink: do we really need to discuss an email sent out? :)
goob: I think no need. We've agreed on what the message should contain. I'm happy to leave fine wording up to them.
flaburgan: it's just to keep track
jaywink: it doesnt' have to be long, just saying that they should be able to provide a running diaspora installation as a demo to us and confirm the minimum specs listed on the page to match that - if not, false promises should be removed?
flaburgan: so, next topic, spammer accounts (it will bring us to the admin task)
flaburgan: do we need something else than captcha?
marekjm: jaywink: exactly that.
goob: jaywink, I think first email can simply request demo pod, and then email to request removal of branding if demo pod not up within two weeks.
goob: (I mean, email again after two weeks).
svbergerem: agree, next topic?
goob: Spammers: there's also the post reporter feature – https://github.com/diaspora/diaspora/pull/4517 – should also help
svbergerem: goob: I agree
goob: Won't stop them signing up, but may get them removed more quickly.
jaywink: need to go guys - thanks for the meeting :) will catch up with logs tomorrow. see ya!
goob: Thanks jaywink. Sleep well, mate.
marekjm: bye jaywink. I'll PM you about the email to that company.
svbergerem: I think captcha and post reporter feature should be fine
flaburgan: we need to provide an easy way for podmins to delete users
svbergerem: thats right
flaburgan: report users is kind of useless with that
flaburgan: without that sorry
flaburgan: so this is the next topic
flaburgan: and last one for today
flaburgan: we need to simply podmins life
flaburgan: the current admin panel is kind of useless
flaburgan: https://wiki.diasporafoundation.org/Meetings/20140114#A_nice_admin_panel
goob: I can agree to 'simplify podmins' lives' and 'improve admin panel'
goob: but what can we usefully decide on here and now?
flaburgan: that this is the priority for the next release?
flaburgan: :p
svbergerem: add feature requests on github?
MrZYX: do you know the facepalm smiley? here it is for you: m( I won't repeat myself another time
flaburgan: https://github.com/diaspora/diaspora/issues/4183
flaburgan: don't get it sorry
MrZYX: things don't happen by saying they're needed
flaburgan: yeah I know
flaburgan: but that's not in my skills at the moment
MrZYX: but that's not relevant
svbergerem: what about the feature requests to keep track of that?
goob: Fla, touché!
marekjm: OK guys, I gotta go. If someone wants to keep pad updated - feel free to. I tried to protocol most of the decisions made so far on the meeting.
svbergerem: (4183 seems to be just about the "clean ghost pods & users)
MrZYX: I think we can wrap up, no?
goob: We can all agree that it's important to improve the podmin experience, but I can't see what we can decide on other than that.
flaburgan: svbergerem, yeah, I'll open a new issue
flaburgan: goob, nothing
flaburgan: I just wanted to point that the focus should be on that for the next release
svbergerem: MrZYX: +1
goob: flaburgan, let's make one of the DHQ posts a request for help on these tasks.
flaburgan: goob, okay
goob: I'm happy to wrap up. Just been writing some minutes which I'll put on the wiki.
flaburgan: everything is already summarized here https://flaburgan.framapad.org/4

Other meetings

Retrieved from "https://wiki.diasporafoundation.org/wiki/index.php?title=Meetings/20140114&oldid=10043"