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..06ef13cf10 --- /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.
+Background and description of the project and idea are +here: +please have a look at this blog if you haven't yet!
+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.
+ + + + + + +