By signing up, you agree to the Code of Conduct, which applies to all online and in-person spaces managed by the Public Lab community and non-profit.

As an open source community, we believe in open licensing of content so that other members of the community can leverage your work legally -- with attribution, of course. By joining the Public Lab site, you agree to release the content you post here under a Creative Commons Attribution Sharealike license, and the hardware designs you post under the CERN Open Hardware License 1.1 (full text). This has the added benefit that others must share their improvements in turn with you.

Brainstorming for Summer of Code 2019

Amazingly, Summer of Code 2019 is approaching, or at least our Ideas list is starting to be needed to plan it out properly. Let's kick off some discussion of projects so that we coordinate the long-term plan for our community's code!

Hi everyone! My name is Igor Wilbert, I'm a computer science from Brazil and I'd like to join GSoC 2019 with Public Lab. Thank you Mr. Warren for introducing me to this post. So far I had two different ideas:
1) Create a mobile version of Public Lab website. I think this is interesting because it can increase the organization popularity (number of people reached) quite a lot. We could start with something simple, an Android app with login, ask, answer and search question functionalities, about us section and maybe others.
2) Incorporating the GloVe: Global Vectors for Word Representation project into the research papers search, or create a search tool dedicated to it. Its learning capabilities might be quite interesting.
Please let me know what do you think. See you!

Hey everyone! I participated in GSoC'2018 as a student developer with public lab. I am also looking for GSoC'2019 opportunity. I have multiple projects in my mind. For now, one of them is :
As publiclab website is getting bigger and lots of new features are getting embedded into it, it is affecting website efficiency and performance and also making the new feature more difficult on the website as the website grows more in future. For such a big website like publiclab we have to move somewhat to any front-end framework in near future. So what we can do is that we can parallelly work on the frontend framework like angular and when it gets mature enough we can replace it with rails frontend. In the process, we can obviously use rails backend which is already made.
This is a very big project (could take a whole year to complete )and I have just added the idea so that people can do brainstorming over it and find out is it worth doing this or not.

I really loved your idea. Yeah this is a huge project but we can plan for the most important part of this project in the GSoC. Other remaining things can be taken up in other contests like GCI'19, Outreachy'19 and so on. I think React will be a better choice than Angular. What do you think?
Let's ask Jeff if he is interested in this migration of frontend. React has a lot of capabilities that we currently miss on pl.org. This will definitely give better UI.

This project will require a lot of needy greedy details for the implementation. We can't directly implement this without the proposal. So, I completely agree with you Naman to have this on GSoC list of 2019. Great idea. Loved it.

Hey everyone! I participated in GSoC'2018 as a student developer with public lab. I am also looking for GSoC'2019 opportunity. I have multiple projects in my mind. For now, one of them is : As publiclab website is getting bigger and lots of new features are getting embedded into it, it is affecting website efficiency and performance and also making the new feature more difficult on the website as the website grows more in future. For such a big website like publiclab we have to move somewhat to any front-end framework in near future. So what we can do is that we can parallelly work on the frontend framework like angular and when it gets mature enough we can replace it with rails frontend. In the process, we can obviously use rails backend which is already made. This is a very big project (could take a whole year to complete )and I have just added the idea so that people can do brainstorming over it and find out is it worth doing this or not.

Thank you, Sidharth!
I was also in the same dilemma whether we should use angular or react but then I realized that we are using rails and angular also follows the same pattern that is model view type of thing(not exactly but the flow is somewhat like that) which makes it easier for our other plots2 contributor to easily get involve in the project even if they donot know angular becuase of similarity of flow between rails and angular. And plus some other advantages of angular is that it is a framework which means it automatically do a lot of thing for us which helps us writing the code faster instead of thinking about the flow just like we have in rails and on the other hand react is a library and lack some of the advantage that we have in angular but it does have some advantage we don't have in angular.
Glad you liked the idea. Let's do brainstroming over it.
Thanks!

Hi @IgorWilbert, I like your idea for the development of Android application. @warren@liz we can be certain about the number of users using our website from mobile devices using Google Analytics if we want to get excited about this project. And, for sure Android app would be super useful to the moderators, without any doubt.

Interesting! I wonder if we might consider a couple things -- an electron-based app that uses largely the same code as the website but is accessible offline? Or something like electron but that runs on Android/iOS...

This might connect with the idea of a client-side framework as well.

One thing we might try to do to approach this in a modular way with minimal disruption could be to think of an initial "app" which does some, but not all, of what the plots2 front-end does. For example, it might be essentially the dashboard, but not include (in an initial implementation) an editor. It might have a way to view a note or wiki, but not have all the many features of those pages unless you "open the full page" so to speak.

The client side system might be launched in parallel to the existing dashboard without replacing it. Then additional views might be built, tested, and added to it gradually. Functions which need a more robust back-end API might be ported as part of this process.

This is just an idea - i think we should think carefully about a large project like this. It may be that we have other priorities like a tag visualization system, better spam management, or a Notifications API which take precedence. We should be careful not to displace those projects. But I really love the brainstorming and careful thought that's going into conceptualizing this and exploring its pros and cons. It may be that we decide that we have enough community to do all the above without compromise! Thank you all!

Thank you for your comment @warren ! Actually from what I know Electron works well for desktop cross-platform development (Windows, Linux etc.), not mobile. With this mindset, what we're looking for is React Native, because it allows development for both Android and iOS using JavaScript (for both front end and back end) and has support for an offline first mode: when the user doesn't have access to internet, it stores updates locally. I believe it would be possible to implement a simplified version of the dashboard and wiki viewer for a GSoC project, perhaps with links to the web-app to access the other functionalities. I agree, working with many projects at the same time disperses effort and we have serious priorities. But sometimes it might be possible to conciliate, for example working on the Notifications API in such a way part of the functionality could be used for the notifications of the mobile app.

And i'd love to brainstorm in a bit more detail how Notifications could be made compatible with both the HTML Notifications API and also a React Native based notifications system. Thank you very much!!

Thank you for your comment @warren ! Actually from what I know Electron works well for desktop cross-platform development (Windows, Linux etc.), not mobile. With this mindset, what we're looking for is React Native, because it allows development for both Android and iOS using JavaScript (for both front end and back end) and has support for an offline first mode: when the user doesn't have access to internet, it stores updates locally. I believe it would be possible to implement a simplified version of the dashboard and wiki viewer for a GSoC project, perhaps with links to the web-app to access the other functionalities. I agree, working with many projects at the same time disperses effort and we have serious priorities. But sometimes it might be possible to conciliate, for example working on the Notifications API in such a way part of the functionality could be used for the notifications of the mobile app.

@warren since both use JavaScript to manipulate HTML, CSS etc., their functionality could be the same, except for that in the mobile version it is not necessary to verify browser support. On the Notification API issue you asked what would happen if two pages were opened at the same time. Several notifications systems (e. g. from LinkedIn or Facebook) work in a way such that notifications pop up in all open pages and if the user sees the notification in one window/page, the notification in other windows disappears as soon as the page is automatically refreshed (the notification is marked as "seen" in the shared backend).
To access the relevance of a mobile app, I checked two fairly trust worth sources [1] [2]. In terms of market share and usage, mobile and desktop together have nearly 100% of the total, each with around 50%. According to [2], in the past two years there was an increase of about 8% in the usage of mobile technologies in the sectors of Science and People and Society. So it is reasonable to expect that once a mobile app for Public Lab (even if very simple, just to view content) is released, the number of people reached eventually will double.
I agree with @gauravano about that it would be important to enable moderation functionalities in the mobile app such as to facilitate the work of moderators, and enable Google Analytics would be quite easy too. Other organizations I contribute to, such as Mifos Initiative and Fossasia, already developed mobile versions of their software (even mobile exclusive software) and the projects weren't abandoned in the long term. We only need to be careful to be open to the biggest number of developers possible. Developing for both Android and iOS is an important step in this direction.

Glad to see the experimental tools category! Like this since it permits end to end analysis of an environmental monitoring effort. Many GSOC efforts are software only; having efforts that focus on software (with hardware) creates more design options and a better understanding of user experience and trade-offs.

Some brainstorming ideas:
-Drones. - Drone imaging is rapidly maturing and should be considered as part of the Public lab remote sensing options. Maybe something like adding NDVI real time collection with other mapping tools such as https://www.opendronemap.org/ .

-Environment Monitoring IoT - Public lab offers great value by providing distributed sensing tools for environmental monitoring. Internet of Things (IoT) has the potential to lower sensor cost and provide a common modular approach. Efforts such as Purple Air and Cogqui are a start but a common collection method and interface such as https://openconnectivity.org/ is needed.

-‘Microscope live stitching blob detection and extraction of larger images from a panning live video feed’ is a great idea but I also know this gets complicated quickly. Some thoughts:

Good catch @MaggPi ! I've made a quick search on the topics you mentioned, I hope it helps.

-Environment Monitoring IoT: in terms of software, EdgeX Foundry Project (https://github.com/edgexfoundry/) by Linux Foundation might be interesting, since it is a unifying platform for several different kinds of IoT sensors, in which they only send a signal if a problem is detected, saving a lot of unnecessary data. In terms of hardware, it could be interesting to integrate a scalable platform with a strong open source support, such as Open Compute Project (https://github.com/opencomputeproject), by Facebook.

My other idea is of having a peer to peer chat in our system using sockets. Sockets can also help us in having the real-time comment on the website without reloading the website and in addition to that we can also use sockets in different part to perform real-time functions in the publiclab website.

Hi @namangupta, great idea. I guess React would be a better choice, because being a UI library, it's pretty lightweight compared to a fully fledged framework such as Angular, and rather than using Angular and writing it from scratch, we can use react-rails, to integrate React with the existing rails views and controllers. Just putting up an idea, let me know what do you think?

Also, apart from integrating with React or any other frontend framework, I guess we can also plan towards making plots2 a PWA, although I see it is not a very big project but can be coupled along with React integration, if we are planning on taking this one up.

Also the idea for using React Native for a native mobile app by @IgorWilbert sounds pretty cool, integration of Google Analytics with React Native is quite simple and essentially, with so many packages for React Native, I guess we will be able to prototype a nice native app for both the platforms(iOS and Android).

Hi @namangupta, regarding sockets, I'd like to suggest looking at the Notification API implementation I mentioned above, as this could play a role in React and other plans here, but is perhaps a bit higher priority for us, as it'd more directly support some of our current infrastructure.

For others, I appreciate the enthusiasm around React, but want to caution that we are most likely to experiment with a single small React prototype that replaces just one interface on the site, in order to learn more about working with React, treat it as a pilot, and evaluate, rather than taking on a really major rewrite as the first step. So if folks are interested in React, I encourage you to consider presenting it as a narrow evaluation project, does that make sense?

Regarding chat, one major consideration is that our current chatroom is quite complex already - we use Riot/Matrix to bridge Gitter, Slack, IRC, and others, and we have some careful bot and settings work keeping that space free of spam abuse. So although we're open to ideas, I think we might be more enthusiastic about some of the "Core mission-driven projects" above. I say this not because I doubt your abilities -- i really appreciate your ambition and enthusiasm!!! But just because these are needs coming from our broader community and we have a responsibility as an organization to prioritize them. Thank you so much!

Hello @warren! Below are my thoughts on some of the ideas I'd love to see implemented in the Editor. Please have a look.

My Ideas (for the PL.Editor)

Complete React migration

The world of components: Components can be implemented to bring different levels of abstraction to the codebase. We can use them to encapsulate similar behaviors in the Editor and group the different ones to create a new behaviour altogether! Components ensure a much more modifiable and readable codebase by providing the bottom-up approach of design.

Stateful, or stateless? React allows you to decide beforehand whether you want your component to work in states or not. Say we need to implement the History module in React. Now the history component maintains "saving" and "not saving" states at any given instant that trigger based on some event logic, say after a number of lines typed by the user and stores the progress. In this particular case we can easily employ a stateful component to fulfill our need to manage local state and need to add logic for event handlers. However, we do not need to maintain any states or employ any logic in order to store the progress of the user. Here we may use a stateless component that simply fetches the top stack element and sends it to the ple-textarea component whenever the user wants to cut back to a previous version. We can also use Redux that comes with Redux DevTools for amazing debugging
possiblities, better state management and an improved workflow altogether.

Life(saving!)cycles: Like anything else in the world, a component comes into existence by birth, grows by getting updates , and after some amout of time, dies, that is, every class(stateful) component, initializes, mounts, updates, and finally unmounts. I won't go into explaining every single one of these here as that would be unnecessary, so instead let's take up an example of when Lifecycles might be of our help. Suppose we need to design an new image upload feature for the Editor. Now one thing we need to understand here is that lifecycles can make our components very detailed in terms of behaviour defining an action for almost every state it is expected to encounter in its lifetime. Whether this is implemented as a React Native app, a DPWA, or a web app, we would want to make sure that if the image is too large, the application continues to upload that in the background when the user switches apps without breaking the upload process. Also, we may want to "integrate" a different technique when the network speed drops below a certain limit for the image upload. To achieve all of this, React allows up to manipulate the cycles to our needs.

Virtual DOM: The Virtual DOM allows the UI to be efficient in diffing UI changes. This step is where React actually does most of its work. It does this using the difference between the last declared render and the updated render in a virtual model of the interface, applying to it the real interface implementation. Hence, React batches the minimum amount of changes needed in each UI cycle, reducing the redraw frequency. Here's a CodePen depicting this. Notice that when you open up the DevTools you will only see the time element refreshing (that is, the diff), and not all of the page at every interval.

Electron implementation

Testing using Spectron and Mocha (using Chai): After pointing the tests to our app's .app or .exe, we'll use Chai and Chai-as-Promised as our helper packages. Tests will more or less be in the same style as Jasmine so contributors shouldn't face a problem writing one.

UI/UX additional support through Photon: Photon is all about that integrated, rich and native feel you get when you execute a proper, solid and well developed application on your system. Action bars, multiple tabs(writing different stuff side by side), Navigational bookmarks, and the Entypo icon font set are the currently staged enhancements I've thought about.

OS exclusive and native cross-platform features: For eg., in macOS 10.14 Mojave, Apple introduced a new system-wide dark mode for all macOS computers. By default Electron apps do not automatically adjust their UI and native interfaces to the dark mode setting when it's enabled. To do so we will toggle our app's dark mode that will be dependant on Mojave's system settings. Native notifications can also be used to capture the user's immediate attention and can be easily constructed in Electron.

Comparatively better performance than native apps: Breaking this up, we have (1) Booting: We'll implement measures such as resolving require() calls ahead of time so that fs.readFileSync() does not trouble us during boot time. Also to achieve high performance while booting, we'll use bendrucker's document-ready package to get the ready signal before executing any non-UI critical code. (2) Prerendering: This can drastically cut down load time (upto 50%) so that the browser can get to painting things on the screen without having to interpret and execute JS in the first place. We'll be making use of patroza's prerender package for this. (3) Idle backgrounds loading using on-idle: We can use this package to load all our processes that can wait, for eg., checking for updates.

Shipping and Automated Updates: We'll leave this for electron-builder to handle.

Having said all this, I have a decent amount of interest in the Editor Overhaul Core-Mission-Driven-Project and look forward to working on it as my GSoC'19 project.

Hi @rexagod ! Very nice ideas! Complete react migration seems quite ambitious, but having developed apps using react and react native I can say that the advantages you highlight are true, and the platform is easy to maintain and scale like few others. If we decide for the migration, you can count on me for any help that you might need developing it my friend!

Hi @warren this is just a light suggestion, I'll flesh it out if you're interested.

How about spam detection with use of machine learning algorithms. We could train our model on public lab specific spam or use something more generic (trained on general spam). Responses could be auto approved unless spam was detected prompting a review :-) I'd propose building the ML aspect using Python libraries (of which I have some experience) and integrating this with the current website.

Hello! My name is Nirav and I am from Mumbai. I would like to join GSoC 2019 with Public Lab. Thankyou for redirecting me towards this post. I would like to contribute to the editors repository and would make it more user friendly and appealing

Hello everyone, i am Manas Mangaonkar, Computer Engineering Undergrad at the University of Mumbai. I would like to be a part of Public Labs 2019 GSOC efforts.I wish to work with public labs because it aims to solve environmental challenges. Something that is very important in this day and age and is a topic dear to me as i have seen huge swats of swampland get destroyed in my region due to urbanisation.

As of now the project i am interested in is the - MapKnitter Exporter - A REST-based Exporting/Queuing system for MapKnitter maps. I saw the GH repo and noticed its written in Javascript,I wish to make a python based exporting/queing system though. will the project maintainers be open to this ?

The experimental section looks interesting as well,i had some ideas but idk how feasible they would be with restrictions on drones. Another one was a live swamp monitoring kit system which runs of solar with a open api for data to be collected.I live in this unique zone where every year migratory birds come like the flamingoes(from russia) come to nest,with each year.Due to rapid ongoing urbanisation and couple of oil spills this has been disturbed a lot,20 years ago the water in the creek towards the sea used to clear,now its murky due to numerous oil spills from ship collisions, wastes etc.

Now this might sound easy,but with the open api and a cluster system with nodes at every point of the outbound water flow channel to the sea, this is going to be a huge project in terms of the code written and sync across devices.

The final aim would be to -

Monitor The water chemical composition as per seasons change with monsoons being the main target bringing in trash from the sea.

OpenCv monitoring of Bird status per season/year along all points of the creek.

OpenApi with a web-based data browser/database for the researcher access.

This would be like a test kit dev project,with this are being the example.The core idea is to have the software and hw in a kit form that can be deployed in similar conditions in the world.For example the swamps in Lousiana, Florida etc.

@warren I will be working on Spectral Workbench Stand-alone capture, please head over to the issue regarding my approach over it. I am part of Public Lab Mentors group where i have solved, reviewed and reported issues. I am part of this community since November 2018.
This is my github handle https://github.com/Dhiraj240 and i hope you will be able to recall me.

Hi, all! Thanks again for your enthusiasm -- I just wanted to note that as @bansal_sidharth2996 has noted, we'll likely be seeking a lot of help with the MapKnitter platform this year. You can read about our upcoming projects in that codebase here:

But it continues into a lot of other work, as roughly outlined. As we start to get our official project ideas page together, we'll be sourcing a good bit from there, so we'd love to hear some brainstorming around that too!

OK, folks, I've compiled an initial list of our Soc Project Ideas from a lot of this brainstorming, incorporating some new ideas, expanding on old ones, and emphasizing MapKnitter a lot. I hope everyone will find ideas they like in this list. We can consider new additions, but this reflects a lot of our mission and focus as an environmental initiative, and it also reflects some careful planning of core projects to lay good groundwork for future projects.

With that in mind, we've focused more on the Notifications API than on React for plots2, but we have also made space for React-based projects to potentially play a role in MapKnitter and Spectral Workbench. I hope the experience and infrastructure we might gain from those projects could be an important part of a prototype React UI on plots2, but I want to be honest that we need to learn more through these prototypes before committing to a major change on plots2. I hope this sounds reasonable!

Hello Everyone. I am happy to see everyone is so enthusiastic. I am Himanshu Dewan and i am currently an undergrad student at University Of Delhi and I am also looking for GSoC'2019 opportunity . My idea is that we should: 1. Develop a PWA
PWA will be a small project and it will add native app like experience . We can use BrowserSyn and WebNotification API . We can use WorkBox that will provide workflow for the project. 2. Migrate to Front End Framework to create a SPA(Single Page Application)
I personally vote to go with react or vue as they are easy to pick up. Although we will have to create lots and lots of API. 3. GraphQL
For creating API we should use GraphQL as this will me more useful to manipulate and access the json data we will need for our frontend and native app.

Hi, i wanted to share a few notes that I wrote in response to an inquiry about the React ideas:

We didn't include the React Native app in our ideas list because it's both not currently a top mission priority for us (although it may be in the future) and I think there are other steps we could take to prepare for it, such as expanding the read/write API, developing Notifications, etc.

However, that's not to say we won't accept a proposal about it. Once all the proposals are submitted, we'll weigh a number of factors:

how many we think we can responsibly support

which are highest priority for the organization

which students seem most likely to succeed (both in completing their project and in building community around it)

and other factors as well! We do sometimes find that we are comfortable enough with a core set of projects and that we have an extra space we are willing to try something a little speculative with. But not always. So our ideas list is intended to help people choose projects that are most likely to be accepted.

With this in mind, there are a few possible ways forward for people looking to do React-based work:

you could submit 2 proposals, one with React Native, and one that more closely aligns with our ideas list. (and, if you finish early, you could just do both :-P)

you could look at how some of the MapKnitter UI projects might be achievable in React, which could then be a component in a React Native app. For example, the Export UI or the Editor UI.

(2) has a few advantages; first, it focuses on a web-first interface which pushes our high priority MK project forward. Second, it involves developing code that would also serve in a RN app; dual purpose. Finally, it pushes forward a core project while demonstrating/prototyping the use of React and even React Native which helps us build confidence and familiarity with React, which could inform future plots2 React work.

I hope this makes sense and seems fair!

Thanks so much for your interest and I look forward to your proposals!

@warren is Notification API is also the part of GSoC idea and what its priority is ?
As this is not a big project for GSoC but we can also include another project along with it. What do you think ?
As I am researching the best way to do it using Action Cables and also researching how we can get notifications using service worker even when the website is not open and when only browser is open and more. So just curious to know.
Thanks

Hi, I am Kunal Vaswani, I have contributed in Public Labs previously.
Here is my github handle: https://github.com/kunalvaswani123
I have good enough experience in ruby, javascript, html, css. I would be helpful for ideas in https://github.com/publiclab/plots2. I am particularly interested in Sensor data upload and display library. I have worked with js libraries like chart.js required for this idea. Is anyone already working on it? if not I'd like to share some of my ideas for this project. Thanks

Hey @warren, as you know that I am working on Sensor Data Upload and display library, here's one of my queries on it:

The point where you mention about implementing a page where per user information about the CSV files is displayed and they can DOWNLOAD them from there, so I have a major doubt there. How are the files stored in our server? Do we use some kind of bucket there or ActiveStorage? And how exactly is that implemented? If you could please shed some light on it, it would be great help.

Folks as the call for proposal is open, I will request all of you to start submitting the proposals in the research notes section at Public Lab. We will be able to review your proposals and give you adequate feedback as soon as possible.

@kvaswani2012 we can discuss the ideas collaboratively. Everyone is welcomed here to share their thoughts.

Hi @ishaGupta18 - thanks, great question. If you drag in a csv file to this comment window, you'll see - it stores it using the Paperclip gem, actually in the Image model (poorly named, sorry!). But we can probably develop a section of the profile page which lists CSVs, because i think there is a content type field on that table:

Hello to the entire PublicLab team,
I'm Álax Alves, a student from Brazil, I have just took notice of Public Lab through GSoC 2019 program. I have recently started to contribute with Public Lab's Mapknitter (https://github.com/publiclab/mapknitter/pull/363). I have great interest in working on the Mapknitter Rails upgrade, since I have experience in those types of migrations (https://gitlab.com/noosfero/noosfero/merge_requests/1438/diffs). I think I could be of great value to the Public Lab team. Along with that migration I plan on making improvements to the entire docker environments, CI configuration.

Hi! We're aiming to use the JavaScript Notifications API, so more like Gitter, less like Facebook, as the initial/main project. However we're leaving open the possibility of a follow-up project that lists all notifications on a page, later. Thanks!

@warren@bansal_sidharth2996@namangupta .. Couldn't we implement both since the one in gitter would work only if someone is online and a recent notifications tab could help the user see all the latest comments and posts while the user was offline. Also, Pop-ups like the one on gitter are quite good but can be easily ignored. An integration of both would be really helpful.

Edit: I just noticed the activity section in PL's dashboard. Isn't it the notifications tab like fb in this discussion?

@warren@bansal_sidharth2996 @namangupta .. Couldn't we implement both since the one in gitter would work only if someone is online and a recent notifications tab could help him see all the latest comments and posts while he was offline. Also Pop - ups like the one on gitter are quite good but can be easily ignored. An integration of both would be really helpful.

Check out the blog at https://publiclab.org/blog | Love our work? Become a Public Lab Sustaining Member today at https://publiclab.org/donate If this email title has an ID in the format #0000, you can reply with the email you use at PublicLab.org and your response will be posted as a comment on the website.

@warren@bansal_sidharth2996 @namangupta .. Couldn't we implement both since the one in gitter would work only if someone is online and a recent notifications tab could help him see all the latest comments and posts while he was offline. Also Pop - ups like the one on gitter are quite good but can be easily ignored. An integration of both would be really helpful.

Check out the blog at https://publiclab.org/blog | Love our work? Become a Public Lab Sustaining Member today at https://publiclab.org/donate If this email title has an ID in the format #0000, you can reply with the email you use at PublicLab.org and your response will be posted as a comment on the website.

I had mostly meant that we ought to focus primarily on the Gitter-type JS Notification API, and if time remains in the summer, to follow-up with the more expanded version. Both is fine! I'm just very focused on achieving our main interest first, and not trying to tackle both at once, if that makes sense 🙌

Check out the blog at https://publiclab.org/blog | Love our work? Become a Public Lab Sustaining Member today at https://publiclab.org/donate If this email title has an ID in the format #0000, you can reply with the email you use at PublicLab.org and your response will be posted as a comment on the website.

Hello dear developers. My name is Maria Belen and I am an undergraduate Computer Science student from Ecuador. I am interested in working on the Leaflet Environmental Layers projects. I have some doubts regarding the milestones. Where can I contact the mentors? Or can I ask here?

Thanks!
I am interested in working on the Leaflet environmental layers project. Will I have to work in all the features or I can choose which ones to implement? I have some ideas for some of the issues. I have worked with open layers and mapnik for the visualization of vector and raster layers, regarding meteorological data, and with leaflet for the visualization of tracks and points in a map.

Hi @mguarand - we would like some of the bigger issues to be solved, but we'll see how far we get over the course of the summer and adjust accordingly. There is also the possibility that more than one person would end up working on the project and we would divide the tasks in 2 or share them!

I'm interested in working on the MapKnitter Image Management project.
But I am not able to understand what is meant by of the listed features
'new templates and APIs to present images on any map, selected by bounding box'
Can someone explain this for me?

Hi! It's a somewhat complex set of projects, but basically, we want to be able to go to a place, shown on a page like https://mapknitter.org/miami (for say, the city of Miami) and see a map of that place. Then, we want to show all the images uploaded within the area shown.

Yes, currently we display only the images associated with the current map. But we'd like to query a new controller method in warpables_controller.rb which would return /all/ images within the current view, and to add them to a new layer group (making sure none are added twice), but not editable. That way you can see other peoples' work alongside your own -- although we'd want an option to hide that layer group in case it starts getting too crowded. This would involve some "bounding box" query in Rails, plus some Leaflet code to display the images.

Check out the blog at https://publiclab.org/blog | Love our work? Become a Public Lab Sustaining Member today at https://publiclab.org/donate If this email title has an ID in the format #0000, you can reply with the email you use at PublicLab.org and your response will be posted as a comment on the website.

Hello everyone!I'm Liang Ting and I am a student from School of Data and Computer Science, Sun Yat-sen University. I am looking for opportunity to take part in Public Labs 2019 GSOC. I am interested in working on the Image Sequencer project. I would like to help to let it have better performance. Learned Multithread, multiprocess programming, and CUDA, I had participated in ASC19 and tried to do some optimization on software. And I have learned about javascript and nodejs before. I see that in the Image Sequencer now, it does not contain much optimization, and the developers want to use webworker and gpu.js to make it work more smoothly. I think I can contribute to it.

@warren may be we can have new project in Image Sequencer as the text overlay was already done 😃 . I have an idea may be we can have a new UI with or without previews and https://github.com/publiclab/image-sequencer/issues/856 this can also be included in it. And few new modules for image sequencer. What do you say about it????