I think Nick’s comment is a good point to restart. (1) communication channel beyond ML As far as I know Slack will not allow guests by self enrollment. If the only problem is in openness, then how about using a Slack bot that makes public archive?
(2) source code management We prefer a version control system integrated with an issue tracking system. As Patric commented, GitHub and JIRA will be a popular choice, and we strongly prefer them. Anthony suggests a contribution workflow with them. For me it looks very attractive idea for practice. Regards, Go Yamamoto On Jun 28, 2017, at 1:47 AM, Nick Kew <[email protected]<mailto:[email protected]>> wrote: On Mon, 2017-06-26 at 11:49 +0200, Patrick Hilt wrote: Dear all, It's clear there is a need to discuss. Unfortunately Miracl has gone through a range of changes which impeded our support for Milagro. However, we still do believe that Milagro is a viable project and would like to see it succeed, albeit with a more focused scope. Looking at the news, it certainly seems a necessity to have an official, open crypto focused project. Agreed there. The question is not whether it's a good project, but whether it's an *Apache* project. I should be sorry to see it retire, but I think if it's to stay, it needs some more committment from the project team. Miracl's support for Milagro does raise an issue here. One of the most important characteristics of an Apache project is that it is NOT so dependent on any single company as to dry up if that company focuses elsewhere. Overall, I totally agree with Go. We need to find a way to communicate and manage a project that works for the contributors. Our "issues" are particularly around real-time communication and GitHub integration (i.e. having bi-directional sync'ing with Apache Git in place, which we've tried to find about a while back). I would echo what Anthony said in reply to Go, and add a few points. Real-time communication channels like Slack are great, up to a point. But they don't provide the same browsable, reviewable record as an email archive (even if publicly archived, real-time chat is too noisy). And Milagro's slack is in private company space most of which is no longer open to me, let alone to a newcomer who would like to lurk quietly before mustering the confidence to participate. Regarding Github integration, that situation has advanced during the time Milagro has been incubating. The project might like to raise the question again on general@incubator. Along with the relationship of Apache and Github JIRA: my current impression is that the github is the more active, though still low-volume. Along those lines, I'd be happy if we could have some guidance from the community. As for "reviving" and moving forward I'd like to propose we 1. determine communication channels beyond just the mailing list; the Milagro Slack channel is not viable imho, since people with random email domains can't add themselves. So we 'd need something else... again, input here would be much appreciated! IRC is a popular baseline. Lots of Apache projects use Freenode. Other channels are also acceptable: can Slack not be configured to permit guest users? 2. determine how we're going to manage source code and stick with that (github vs. git); from my perspective I have a strong preference for github. So any info on bidirectional sync or best practises / approaches from other Apache projects would be hugely appreciated general@incubator would be a good place to raise that. My own exposure to full github integration is from Trafficserver, which was one of the Apache projects to trial it. When Milagro first entered the incubator, infra were clear: it wasn't yet being rolled out beyond the trial projects. 3. take stock of where we are currently in terms of contributors, pending code, etc. Indeed. How has staff turnover at Miracl affected the roster? In an ideal world it shouldn't, except insofar as new developers may be recruited to relevant work. 4. chart a course forward in small incremental steps based on the above We have a chicken-and-egg here. An active and healthy community draws interest. The hard part is to bootstrap that community. Currently we have a codebase that draws some interest, generally through github, but at a modest level. The individual who provides fast and excellent replies to most of the github issues has (I think) never put in an appearance at Apache. I believe it would be useful to do 3. and 4. in-person / in-call, at least partially. Happy to give it a try, with a couple of reservations: (a) Concern that it might reinforce a top-down process that works in a company context but the team needs to get away from at Apache. (b) A hint of deja-vu. [Go wrote re: merge of NTT codebase] Please advise us how we should communicate. This mailinglist is always the primary channel for project communication. Issues raised by a large volume of NTT code to merge with the current (Miracl) codebase might be a very good start to substantive activity here! Both Miracl and NTT may need to make efforts to resist a natural temptation to make decisions in private and only communicate to the list once decisions are made! -- Nick Kew ________________________________ This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT I3 makes no warranty that this email is error or virus free. Thank you. ________________________________
