diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000000..e69de29bb2 diff --git a/404.html b/404.html new file mode 100644 index 0000000000..b299b29d03 --- /dev/null +++ b/404.html @@ -0,0 +1,831 @@ + + + +
+ + + + + + + + + + + + + + + + +It started as Ivan's idea to build FMTM (Ivan Gayton is Senior Humanitarian Advisor at Humanitarian OpenStreetMap Team) which then became a collaborative project with the efforts of Ivan , Rob Savoye who is Senior Technical Lead at Humanitarian OpenStreetMap Team and many other members from HOT as well as volunteers interested in the project. +HOT uses ODK heavily, but most of the data never makes it into OSM because all the data processing is manual and slow, so it doesn't get done. +Ivan Gayton(Senior Humanitarian Advisor at Humanitarian OpenStreetMap Team) heard about what Rob was working on and goes "That's the missing piece I needed!". He'd been wanting to build FMTM for years, but lacked the ability to process the data.A webinar then took place in September 2022 that showcased the high interest from the community and the need for collaborative field mapping that really kicked off the starting point for building the Field Mapping Tasking Manager. It was Ivan who got HOT interested enough to direct some resources to his idea, so FMTM was born.
+ + +Want to know about OSM-fieldwork project ? Click here
+
+
+
+
The Field Mapping Tasking Manager (FMTM) is a project that aims to provide tools for coordinating field mapping activities in Open Mapping campaigns. While there are existing field mapping applications, there is a lack of efficient tools to coordinate these activities. The FMTM builds on the HOT Tasking Manager and other mapping applications to provide a more streamlined and organized process for completing mapping tasks.
+Currently, it is possible to implement a Field Mapping Tasking Manager workflow using existing tools, but it requires significant effort and can be challenging. The FMTM project is developing automation features to address these challenges and make the process more accessible to users.
+By providing a centralized platform for organizing and managing mapping tasks, assigning them to specific users, and tracking their progress, the FMTM aims to simplify the coordination of mapping activities. The tool also provides analytics and reporting features, allowing users to gain insights into mapping campaigns and adjust their strategies accordingly.
+ +The FMTM project is open source and community-driven, welcoming contributions from designers, user testers, and both front-end and back-end developers. If you're interested in getting involved, please see our contributor guidelines for more information. We welcome questions and feedback, so don't hesitate to reach out to us. 👍🎉
+OpenDataKit's Select From Map feature is a useful tool for field mappers to collect data in a well-structured questionnaire format. The tool was incorporated into ODK in mid-2022 and allows mappers to select an object from a map, view its existing attributes, and fill out a form with new information and attributes.
+To prepare map files for ODK, inspiration is taken from the HOT Tasking Manager, which allows remote mappers to choose well-defined small "task" areas, ensuring full coverage of the project area and no unintended duplication of tasks. For example, a mapper can approach a building, select that building from a map view within ODK on their mobile phone, and add the opening hours, number of floors, construction material, or any number of useful attributes in a well-structured questionnaire format
+ + +To prepare the appropriate map files for ODK, we are taking our inspiration from the HOT Tasking Manager, which allows remote mappers to choose well-defined small "task" areas, ensuring full coverage of the project area and no unintended duplication of tasks.
+ + +There are three main user roles for using ODK's Select From Map feature: campaign managers, field mappers, and validators.
+Campaign managers select an Area of Interest (AOI) and organize field mappers to go out and collect data. They need to:
+ +Field mappers select (or are allocated) individual tasks within a project AOI and use ODK Collect to gather data in those areas. They need to:
+Validators review the data collected by field mappers and assess its quality. If the data is good, the validators merge the portion of the data that belongs in OpenStreetMap to OSM. If it requires more work, the validators either fix it themselves (for minor stuff like spelling or capitalization mistakes that don't seem to be systematic) or inform the field mappers that they need to fix it. They need to:
+For this visit the +Getting Started Page.
+ + + + + + +(The latest version can be found at https://www.hotosm.org/code-of-conduct)
+Welcome to Humanitarian OpenStreetMap Team. HOT is committed to providing a welcoming and safe environment for people of all races, gender identities, gender expressions, sexual orientations, physical abilities, physical appearances, socio-economic backgrounds, nationalities, ages, religions, and beliefs.
+The HOT community principles are:
+Be friendly and patient. Be generous and kind in both giving and accepting critique. Critique is a natural and important part of our culture. Good critiques are kind, respectful, clear, and constructive, focused on goals and requirements rather than personal preferences. You are expected to give and receive criticism with grace. Be considerate in speech and actions, and actively seek to acknowledge and respect the boundaries of fellow attendees.
+Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. Some examples of behavior that contributes to creating a positive environment include:
+Using welcoming and inclusive language.
+Being respectful of differing viewpoints and experiences.
+Gracefully accepting constructive criticism.
+Showing empathy towards other community members.
+Placing collective interest before your own interest.
+Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we're a world-wide community, so you might not be communicating in someone else's primary language.
+Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the HOT community should be respectful when dealing with other members as well as with people outside the HOT community.
+Be careful in your word choice. We are a global community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren't acceptable. This includes, but is not limited to:
+Violent threats or language directed against another person.
+Discriminatory jokes and language.
+Posting sexually explicit or violent material.
+Posting (or threatening to post) other people's personally identifying information ("doxing").
+Personal insults, especially those using racist or sexist terms.
+Unwelcome sexual attention.
+Advocating for, or encouraging, any of the above behavior.
+Repeated harassment of others. In general, if someone asks you to stop, then stop.
+Assume all communications are positive. Always remain polite, and assume good faith. It is surprisingly easy to misunderstand each other, be it online or in person, particularly in such a culturally diverse setting as ours. Misunderstandings are particularly easy to arise when we are in a rush, or otherwise distracted. Please ask clarifying questions before assuming that a communication was inappropriate.
+When we disagree, try to understand why. Disagreements, both social and technical, happen easily and often. It is important that we resolve such disagreements and differing views constructively. At times it can be hard to appreciate a viewpoint that contradicts your own perceptions. Instead of pushing back, try to understand where the other person is coming from, and don’t be afraid to ask questions. You can be most helpful if your own replies serve to clarify, rather than to escalate an issue. Also don’t forget that it can be easy to make mistakes, and allow for the possibility that the mistake may have been yours. When this happens it is better to resolve the issue together, and to learn from the experience together, than to place blame.
+Original text courtesy of the Speak Up! project.
+Further sources:
+Ada Initiative: HOWTO design a code of conduct for your community
+Contributor Covenant – A Code of Conduct for Open Source Projects
+As a first measure, it is preferable to work out issues directly with the people involved, or to work with other Community Members who can help you resolve the issue. This may take several forms:
+Talk with one another. Assume that communications are positive and that people are treating each other with respect. Cues about emotions are often lacking from digital communications. Many of our modes of digital communication tend towards brevity, which can be easier to interpret incorrectly as being negative.
+Contact a representative of the Community Working Group, which exists to support the HOT Community. Representatives are available to discuss any concerns about behaviour within the community, or ideas to promote positive behaviours. You can email them at community@hotosm.org.
+Contact a representative of the Governance Working Group, which drafted these recommendations and the CoC. Representatives are available to provide advice on particular scenarios, as well as on the processes around the CoC.
+Contact the HOT Chair of Voting Members.
+Contact a HOT Board Member. Board members are well versed in the community and its management. They can offer advice on your particular situation, and know the resources of the organization that may be available to you.
+Contact the HOT Community Partnerships Manager.
+When these informal processes fail, or when a situation warrants an immediate response by HOT, you can evoke the HOT Policy and Code of Conduct Complaint Handling Process. This process was adopted by HOT Voting Members in 2016 to provide a more formal means of enforcement for our community standards. You start it by emailing complaints@hotosm.org with a description of your complaint, your name, and the name of the offending party. All complaints will be considered confidential. The full process is described here .
+ + + + + + +First off, We are really glad you're reading this, because we need volunteer developers to help improve the Field Mapping Tasking Manager (FMTM)!
+We welcome and encourage contributors of all skill levels, and we are committed to making sure your participation is inclusive, enjoyable, and rewarding. If you have never contributed to an open source project before, we are a good place to start, and we will make sure you are supported every step of the way. If you have any questions, please ask!
+You can see an overview of the project and the process we have gone through in developing FMTM so far in these slides .
+Furthermore, there are many ways to contribute to the Field Mapping Tasking Manager (FMTM), which includes:
+Right now, we are in the process of building the prototype. We warmly welcome your input in testing and sharing your feedback. If you are also interested in coordinating a field testing session, please reach out!
+Create pull requests (PRs) for changes that you think are needed. We would really appreciate your help!
+Skills with the following would be beneficial:
+Our latest task board can be found here.
+The issue queue is the best way to get started. There are issue templates for BUGs and FEATURES that you can use, you could also create your own. Once you have submitted an issue, it will be assigned one label from the following label categories. If you are wondering where to start, you can filter by the good first issue label.
+Thank you very much in advance for your contributions!! Please ensure you refer to our Code of Conduct. +If you've read the guidelines, but are still not sure how to contribute on Github, please reach out to us via our Slack #geospatial-tech-and-innovation.
+We operate the "Fork & Pull" model explained at About Pull +Requests
+You should fork the project into your own repo, create a topic branch +there and then make one or more pull requests back to the repository. +Your pull requests will then be reviewed and discussed by other +developers. Don't submit a Pull Request while still developing the +code, wait till the feature is complete and ready for review. A +preliminary review by other developers can be requested via the +comments for the issue on github, or via slack or email.
+It is prefered that all patches contain any documentation +updates made, and for any new features, a test case is preferred when +possible. Keep patches focused on a single feature to avoid merging +complications with other developers. The old free software joke is +"patches are better than bug reports" is how we contribute to the +community of people involved with this project.
+Describe exactly what you were trying to achieve, what you did, what you + expected to happen and what did happen instead. Include relevant information + about the platform, OS version etc. you are using. Include shell commands you + typed in, log files, errors messages etc.
+Please open a separate issue for each problem, question, or comment you have. + Do not re-use existing issues for other topics, even if they are similar. This + keeps issues small and manageable and makes it much easier to follow through + and make sure each problem is taken care of.
+Project documentation should be in Markdown +format, and in a docs +subdirectory. While it is possible to use HTML in Markdown documents +for tables and images, it is prefered to use the Markdown style as +it's much easier to read.
+Python enforces a certain amount of style due to indent levels. Unlike +C/C++, we don't have to worry about curly braces. It is prefered that +all code follows object oriented techniques, with a minimal amount of +code other than basic control in the main function. This allows code +to be easily reused and run either standalone, or part of a REST API +backend. Code that is not designed to be run standalone can have a +main function to do simple testing during development. That test code +should be moved to a standalone test case when possible. +Pytest is used as the test framework for +standalone test cases.
+Code follows a CamelCase +style. Classes use an Upper Case for the first word, method use a +lower case for the first word. Variable names are all lower case with +an underbar as a word separator. Properly naming everything makes it +much easier to read the code and get an idea of what it is doing. This +enables people new to this project to contribute easier.
+All methods should have a comment that can be used by +pydoc. The usage of +base classes is encouraged so functionality can be shared. Comments in +the code are encouraged when necessary to explain code that may not be +obvious, but avoid over commenting as well. Code should be able to be +read like a book, with descriptive names used, no fancy tricks unless +required. Always be concious of performance and security.
+ + + + + + +